The Handbook of Financial Modeling: A Practical Approach to Creating and Implementing Valuation Projection Models [2 ed.] 1484265394, 9781484265390

Table of contents :
Contents
About the Author
Acknowledgments
Introduction
Chapter 1: The Role of a Financial Modeler Today
The financial modeler
Where financial modelers are being used
Modeling roles for the future
Data and business intelligence possible job specification
Expert systems’ possible job specification
Commercial and business possible job specification
Conclusion
Chapter 2: Types of Financial Models
Financial statement models
Understanding the financial statements
Cash vs. accrual
What about cash flow?
How the income statement, cash flow, and balance sheet are linked
Net earnings
Depreciation and amortization
The working capital
Getting the cash
Consolidation model
Watch the file size
Complex links
Be clear about the outputs
Mergers and acquisition models
The M&A model nuisances
Create operational forecast
Build the assumptions
Projections
Combine the acquirer and the target companies
Leveraged buyout model (LBO)
Collect purchase price assumptions
Create sources and uses list
Create financial projections
Transaction balance sheet adjustments
Debt and interest schedule
Credit metrics
Calculate DCF and IRR on initial investment
Exit
Budget and forecast models
Establish the historical data
Create a template for the assumptions
Run assumptions against the historical data
Develop the outputs
Compare
Conclusion
Chapter 3: Review of Best Practices for Financial Modelers
Workbook assumptions
Workbook cover
Workbook table of contents
Workbook styles
Worksheet classification
Worksheet titles
Worksheet documentation
Worksheet error checking
Keep constituents separate
Reduce implicit assumptions to minimum
No constants within a formula
Inputs drive the model, not calculations
One input to an assumption
Specify the units of measurement
Logic flow of calculations
Avoid circularities
Consistent formula across rows
Do not mix time periods
Avoid long and complex formula constructions
Merge cells on data
Avoid fonts with same color background
Avoid using VBA on critical calculations
Conclusion
Chapter 4: The Modeling Life Cycle Explained
Feasibility
The draft modeling project scope
The current analysis
Current requirements
The approach
Evaluation
Review
Conclusion
Scope
Key concepts of a project scope
Project justification
Project scope objectives
Product scope description
Model acceptance criteria
Project constraints
Project assumptions
Requirements
Conclusion of requirements
Specifications
Documentation and timelines
Financial modeling project plan
Goal log
Risk log
Issue log
Model design
Model build
Model testing
Model review
Handover and maintenance
Conclusion
Chapter 5: Planning and Designing Models
Planning to build a model
Having an understanding of cash?
It’s all in the detail!
Create scenario analysis and sensitivity analysis
Assumptions: how realistic are they?
Missing key elements in financial statements
Build a realistic timeline
Know the key metrics and indicators
Developing a feasibility assessment
Scoping the modeling project
The specification and strategy
Defining model outputs
Defining calculations
Defining the inputs
Designing the financial model
Managing complexity
Building your model
Define the modeling tool(s) for the job
Have a clear approach
Get approval of the outputs
Timescales
Developing styles and templates
Define the structure of the workbook
Working with the inputs
Working with the calculations
Working with the outputs
Recap
Planning for errors
Creating the error template
Displaying the errors
Example of planning a financial model
The brief
About the feasibility study
The assessment
Problem statement
Business environment
Business vision
Business units
Business location
Business information
Business technologies
Business problem
Business opportunity
Requirements statement
Business drivers
Business requirements
Feasibility assessment
Option one: Implementing off-the-shelf software
Description
Assessment
Results
Risks
Issues
Assumptions
Option two: Developing a financial model tool
Description
Assessmentx
Results
Risks
Issues
Assumptions
Feasibility ranking
Ranking criteria
Ranking scores
Feasibility result
Conclusion
Chapter 6: It’s All About the Outputs
Deriving the outputs
A sample output
Step 1: build the inputs
Step 2: take the inputs into the workings
Step 3: link the workings to the outputs
Conclusion
Chapter 7: Model Build
Setting the environment
The scope
The requirements and specifications
Step 1: Deciding the type of model
Step 2: Creating the worksheet template
Step 3: Create the model style worksheet
Step 4: Time for some control
Step 5: Create the model cover worksheet
Step 6: Build your timeline template
Step 7: Inputs, set up the constants
Step 8: Inputs, create data input template
Step 9: Inputs, create scenario inputs
Step 10: Inputs, allocations
Step 11: The calculations (workings) worksheet
Step 12: Create error checking
Step 13: Build in the documentation
Step 14: Added-value modeling
Conclusion
Chapter 8: Financial Modeling and Accountancy
Accounting primer
The need for accounting
Accounting and business
Sole proprietorships
Partnerships
General partnership
Limited partnership
Master limited partnership
Corporation
Types of accounting
Cash-based accounting
Accrual accounting
Cash vs. accrual accounting
Accounts
Account types
Assets
Liabilities
Long-term liabilities
Capital
Key accounting concepts
The accounting equation
Assets = owner’s equity
Assets = liabilities + owner’s equity
The double-entry system
Assets = liabilities + owner’s equity
Journals
Chapter 9: The Implications of Accounting Rules for Modelers
Linking inputs to financials
Understanding when to use financial statements
Chapter 10: Modeling Scenarios Explored
The importance of the start dates
Reflecting real or nominal costs
Dealing with discounts
We need our margin
Chapter 11: Calculations for Financial Modelers
The difference between functions and formulas
The base functions
Worksheet headers and labels
The SUM() function
SUBTOTAL()
Lookups and math
INT()
MOD()
INDEX()
MATCH()
INDEX() and MATCH() combined
Other useful functions
IFERROR()
EOMONTH()
Using best practice calculations
Whole range calculations
Calculating time periods
Array calculations for single values
Formulas that are based on a condition
Getting the closest match to an input target
Using crosstab calculations
Applying the right function to your calculations
Functions that look up information
Functions that require a condition
Functions that are driven by dates
Functions for precise situations
Mathematical functions
Functions dependent on text
Calculations involving logical and information functions
Math in modeling
BODMAS
The math in formulas
Conclusion on calculations
Chapter 12: The Importance of Documentation
Providing documentation in models
Documentation structures
Introduction
Assumptions and inputs
Macro handling
Outputs
Known issues
Documentation standards
Using cell comments
Thoughts about the application to be used
Chapter 13: Model Stress Testing
Why test?
Who should test?
When to test?
Types of tests
The test plan
Numeric tests
Robustness tests
Environment tests
Boundary tests
Macro tests
Specification tests
Unique formula tests
Black box testing
White box testing
Error handling testing
Compliance or static testing
Management control testing
Stress test
System performance test
Functional testing
What do you test in functional testing?
How to test your model
The testing cycle
Common types of errors to test
Formulas not copied
Wrong reference
Sum over the wrong range
Relative and absolute references
Unit errors
Commonly misused functions
Other functions that often cause errors
The test file
Change requests
Points to keep in mind when testing
Chapter 14: Model Audit and Review
How to perform a model audit
The process
The low-level review
The high-level review
Sensitivities
Final review report
Final say
Chapter 15: The Role of VBA in Financial Models
What is VBA?
Using Visual Basic for Applications (VBA) in financial models
The Visual Basic Editor (VBE) in Excel
Basic understanding of VBA
Coding in VBA for modelers
VBA project explorer and code windows
Case study: how VBA benefits models
Why is VBA good for modeling?
Reduces manual time
Provides quicker processing times
Utilizes events
Enhances the model user’s experience
Chapter 16: Operis
Introducing Operis
How Operis structures its work teams
Operis and financial modelling teams’ careers
Overview and conclusion
Chapter 17: Financial Modeling, Where Next?
Future demand for financial modeling
Evolutions in financial modeling
Appendix A:
Modeling Glossary and Terminology
Income statement terms
Cash flow statement terms
Balance sheet terms
Appendix B:
Ready-Made Functions
Appendix C:
References
Index

Citation preview

The Handbook of Financial Modeling A Practical Approach to Creating and Implementing Valuation Projection Models ― Second Edition ― Jack Avon

THE HANDBOOK OF FINANCIAL MODELING A PRACTICAL APPROACH TO CREATING AND  IMPLEMENTING VALUATION PROJECTION MODELS SECOND EDITION

Jack Avon

The Handbook of Financial Modeling: A Practical Approach to Creating and Implementing Valuation Projection Models Jack Avon Riberac, France ISBN-13 (pbk): 978-1-4842-6539-0  https://doi.org/10.1007/978-1-4842-6540-6

ISBN-13 (electronic): 978-1-4842-6540-6

Copyright © 2021 by Jack Avon This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. The publisher makes no warranty, express or implied, with respect to the material contained herein. Managing Director, Apress Media LLC: Welmoed Spahr Acquisitions Editor: Shiva Ramachandran Development Editor: Matthew Moodie Coordinating Editor: Nancy Chen Cover designed by eStudioCalamar Distributed to the book trade worldwide by Springer Science+Business Media New  York, 1 New  York Plaza, New  York, NY 100043. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail [email protected], or visit www.springeronline.com. Apress Media, LLC is a California LLC and the sole member (owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance Inc is a Delaware corporation. For information on translations, please e-mail [email protected]; for reprint, paperback, or audio rights, please e-mail [email protected]. Apress titles may be purchased in bulk for academic, corporate, or promotional use. eBook versions and licenses are also available for most titles. For more information, reference our Print and eBook Bulk Sales web page at http://www.apress.com/bulk-sales. Any source code or other supplementary material referenced by the author in this book is available to readers on GitHub via the book’s product page, located at www.apress.com/9781484265390. For more detailed information, please visit http://www.apress.com/source-code. Printed on acid-free paper

This book is dedicated to those who have difficulty seeing similarities and differences in words and letters, difficulty with reading and mispronouncing familiar words. Don't let dyslexia stop you from reaching for the sky!

Contents About the Author����������������������������������������������������������������������������������������������������vii Acknowledgments�������������������������������������������������������������������������������������������������� ix Introduction�������������������������������������������������������������������������������������������������������������� xi Chapter 1:

The Role of a Financial Modeler Today���������������������������������   1

Chapter 2: Types of Financial Models���������������������������������������������������������   9 Chapter 3: Review of Best Practices for Financial Modelers ���������������  39 Chapter 4: The Modeling Life Cycle Explained ���������������������������������������  65 Chapter 5: Planning and Designing Models�����������������������������������������������  85 Chapter 6: It’s All About the Outputs��������������������������������������������������������� 131 Chapter 7: Model Build����������������������������������������������������������������������������������� 141 Chapter 8: Financial Modeling and Accountancy������������������������������������� 173 Chapter 9: The Implications of Accounting Rules for Modelers ��������� 191 Chapter 10: Modeling Scenarios Explored��������������������������������������������������� 201 Chapter 11: Calculations for Financial Modelers��������������������������������������� 217 Chapter 12: The Importance of Documentation��������������������������������������� 259 Chapter 13: Model Stress Testing������������������������������������������������������������������� 265 Chapter 14: Model Audit and Review ����������������������������������������������������������� 289 Chapter 15: The Role of VBA in Financial Models������������������������������������� 299 Chapter 16: Operis��������������������������������������������������������������������������������������������� 315 Chapter 17: Financial Modeling, Where Next?������������������������������������������� 325 A  ppendix A: Modeling Glossary and Terminology ������������������������������������� 329 A  ppendix B: Ready-Made Functions��������������������������������������������������������������� 333 A  ppendix C: References������������������������������������������������������������������������������������� 343 I ndex ����������������������������������������������������������������������������������������������������������������������� 345

About the Author Jack Avon first used Microsoft Excel in 1990, and from then onward, started to build spreadsheet models to this day. Avon provides consulting services to corporations worldwide on how to integrate in-house ERP systems with bespoke financial models and delivers business intelligence processes. He also trains corporate personnel and develops training manuals in financial modeling. In his leisure time, he enjoys all aspects of photography and runs a small business that services and repairs vintage and modern cameras. Jack Avon lives in a small countryside town in the southwest of France near Bordeaux with his wife and children where the pace of life is slow and the simple things mean so much.

Acknowledgments Writing a book outwardly appears to be a solitary affair, but I can tell you that’s far from the truth, because there will always be people who have either directly or indirectly contributed to that finished manuscript. None of this would have been possible without Hugh Blake. He was my mentor and opened my eyes to possibilities all those years back. I am eternally grateful to Shivangi Ramachandran from Apress who took the time to hear my story and champion this book to the publishing board. To Nancy Chen at Apress for keeping me steered on the correct course and giving considerable positive encouragement all the way through the writing process. To my longtime friends Colin and Charles Scragg for boosting my ego when it was low and giving me belief that I can write. To all my Dordogne crew who always asked me how my writing was shaping up and gave me so many great words of advice over a great French wine. To my family, my dad and mum, Roger and Esnat, who without realizing checked up on me every week to see that I was making each chapter of the book work. My siblings Lillian, Paul, Kelvin, and Kate for doing all they could to support me. To my son Luke who has always given me unquestioned support about what I do and continues to make me proud of his achievements every day of my life. My grandsons Leo and Carter, though you are just little know I hope one day to share a read of one chapter with you. Finally, to my wife Jenny who, despite very difficult times with the COVID-19 lockdown, provided me with the environment to write and complete this book. To my daughter and son, Natty and Thandi, for questioning me daily about what this book is about and keeping me true.

Introduction When I wrote the Handbook of Financial Modeling in 2013, the expectations of a financial modeler have gone through many changes in just seven years. In this second edition, I will not only be highlighting those changes but also giving an insight into how the future of financial modeling could develop. Financial models are predominantly developed using Microsoft Excel, which means there are no two models that look the same. This presents problems for users of models, because there is no uniformity as to the look and feel of a financial model. To address this problem, there is a full chapter in this edition devoted to financial modeling best practices. I am emphasizing best practices throughout this edition because this is a facet of real-world financial modeling that seems to have been neglected in modern financial models. The need for financial modelers has increased considerably in the last 10 years, to the extent that many of the international professional services firms like KPMG, EY, and PWC now have entrenched revenue streams providing financial modeling services. Several organizations have emerged and prospered as dedicated international financial modeling companies in their own right like Operis and Modano. In fact, since the last edition, we now have annual financial modeling competitions like ModelOff to assess who are the best modelers in the world. Financial models are used commercially in just about every industry including insurance, banking, engineering, manufacturing, retail, and travel. Increasingly, financial modeling is seen as a viable career path in its own right, and it’s now possible for an individual to begin a modeling career right after graduating from university or college. The skills of today’s modelers have expanded considerably over the last 7 years. Financial modelers now tend to have hybrid skills and experiences in IT, data analysis, commercial business, and finance. There is also a high expectation that a financial modeler is highly skilled in the use of Microsoft Excel. Excel spreadsheets are still one of the most utilized business tools worldwide, but in the hands of a skilled financial modeler, these spreadsheets can be transformed into very powerful forecasting tools.

xii

Introduction I use the term modeler throughout this edition as a shorthand for financial modeler, just to avoid any confusion. I hope that you will not only read this second edition but will enjoy acquiring the skills and knowledge to propel yourself into what is a very rewarding and exciting future as a financial modeler.

CHAPTER

1 The Role of a Financial Modeler Today This chapter serves as background to financial modeling from the perspective of the individual person. There are possibilities now for individuals to enter a career as financial modeler. Many organizations will openly advertise job titles as “financial modelers” or “business modelers.” Here, we can take a look at some real-world roles and examine their impact on financial modeling and also what they are looking for in a candidate.

The financial modeler Financial modeling is a very specific discipline that often uses spreadsheets in the shape of Microsoft Excel. Typically, the financial modeler’s prime responsibility is to deliver a specified financial model. To deliver a financial model will require the modeler to perform several activities and tasks including •• Evaluating the type of model required •• Specifying and collecting the requirements of the to-be model © Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6_1

2

Chapter 1 | The Role of a Financial Modeler Today •• The design and build of the model •• Validation of the data for the model •• Testing and documenting of the model •• Data validation and populating of the model •• Security and handover Depending on the requirements of the modeling project, a modeler could be expected to manage the financial modeling process—from the start of the project to when the model is delivered and in use. (This process is discussed in greater detail in Chapter 4.) The backgrounds of financial modelers are varied. Once upon a time, it would have been safe to assume modelers were accountants; however, it would be a great injustice to other professions to make that assumption today. One of the reasons why the accounting profession has been a breeding ground for modelers is that much of financial modeling requires the modeler to have a good grasp of a large host of financial concepts. However, this is by no means the main requirement for being a professional financial modeler. Nowadays, the principal qualities required of financial modelers are less about professional standing and more about the commercial experience and technical abilities. To be successful as a modeler, individuals need to ••

Be profoundly analytical and questioning by nature

••

Be comfortable communicating to people of any background and at any level in an organization

••

Have an innate ability in identifying the key elements that drive any information output

Where financial modelers are being used When we talk about financial modeling, we are really looking at quite a range of domains, including data analysis, financial management, project finance, business intelligence, and commercial business analysis. It’s more often than not that modelers will not necessarily have “financial modeler” in their job title. Instead, modeling will be a significant part of the role expectation. Therefore, for financial modelers, roles will be disguised in other corporatespecific job titles. Many modelers can be found in areas such as ••

Investment analysis: Banking analysts and associates spend most of their time looking at mergers and acquisitions, raising capital, debt equity, and public offerings. There are many modelers who start out in this field.

The Handbook of Financial Modeling ••

Equity research analysis: These are analysts who routinely research industry trends and movements and also corporate trends. They make comparisons between corporations and seek to give a view on where future growth will come from. There is a heavy reliance on modeling skills in these roles.

••

Financial planning and analysis: The modelers are responsible for forecasting business performance and forecasting growth within an organization. This role is generally the preserve of accountants and modelers.

•• Venture capital: These modelers work on preparing and calculating the level of investments and returns in earlystage businesses. This is one area that is full of freelance modelers. ••

Insurance and actuarial: The modelers in this field are quite specialized. Most modelers who start out here will remain in insurance. There is a strong barrier to entry for many modelers because to be a modeler in an actuarial environment, one is required to be an actuary with several years of experience.

••

Real estate and asset management: These areas tend to use models heavily to forecast yields, amortization, cash flow, and payback benefits. This is a very popular area for freelance modelers working on a project-by-project basis. Modelers in this area tend to have several years of experience and have a very high professional indemnity insurance cover. This is an area where the risks of making mistakes can lead to litigation and therefore will be for modelers.

••

Project finance: Modelers assess the feasibility of a project from several different angles (not just cash flow return) and must have a very good understanding of financial concepts and financial regulatory requirements. This area attracts modelers from banking and also those who worked for the professional services firms.

••

Startups: There are modelers who specialize in working with startup organizations. These modelers usually are freelancers with several years of experience often in nonmodeling roles. By far, the trend for modelers in this area tends to be accountants.

3

4

Chapter 1 | The Role of a Financial Modeler Today A characteristic of the modelers who work within job areas listed is they are almost always business as usual (BAU) in manner as opposed to project work. BAU working is when an individual continues to produce their work regardless of the current circumstances. Project working is when an unusual circumstance arises which will have a specific start and end date. A large proportion of financial modelers are freelancers working exclusively on projects. These freelance modelers work as consultants in just about every industry on specialist projects, working with one or more clients at the same time.

Modeling roles for the future Although financial modeling is still in its infancy as a career path, based on demand there is clear evidence modelers will continue to be a requirement in business and commerce in the future. I would like to use just explore the idea of how financial modeling roles will look in the future. I believe there will be a shift in the type of skills required in financial modeling. This movement is already started to happen but is at its early stages. There will be a move to more specialism based on types of businesses. The role “financial modeler” will all but disappear because every modeler will be expected to have the foundation in modeling and then a specialism. The broader areas of specialism will be •• Data and business intelligence •• Expert systems •• Commercial and business Let me give you an example of a job title and job specification on each of the three domains.

 ata and business intelligence possible job D specification The following is a list of hypothetical job specifications, and is not based on any current jobs: •• Develop and maintain an end-to-end business intelligence process. •• Collaborate with internal business users. •• Drive requirements and specify the process.

The Handbook of Financial Modeling •• Deliver reports and portable models across the business (financial modeling). •• Create and maintain documentation (requirements, user manuals). •• Identify and solve ad hoc business needs (financial modeling). •• Business intelligence analysis. Requirements •• College or university degree in information technology, finance, or something similar •• Data analysis and data integration skills including SQL and SSRS ••

Knowledge of technologies (Power BI, Tableau, QlikView, or something similar)

•• Excellent analytical and problem-solving skills •• Advanced Excel and VBA •• Prior experience in a financial modeling role This role is reasonably general toward data analysis and business intelligence; however while currently financial modeling and business intelligence are separate skill sets, expect these to combine in the future. The role would likely be called business intelligence specialist, but would also mean financial modeling.

Expert systems’ possible job specification Expert systems were very prominent in the early 1990s, and there were high expectations that in the future, everything would be based around these systems. The job specification would look something like this: •• Design machine learning systems. •• Develop machine learning applications and outputs according to business user needs (some financial modeling). •• Understand the methods of selecting appropriate data set and data tools. •• Seek requirements from the business communities and facilitate solutions.

5

6

Chapter 1 | The Role of a Financial Modeler Today •• Deliver reports and output models across the business (financial modeling). •• Create and maintain documentation (requirements, user manuals). Requirements •• College or university degree in computer science, engineering, finance, or something similar •• Postgraduate or professional membership in finance, IT, and engineering •• Knowledge of data analysis principles and data governance •• Advanced experience in technologies (C++, Python, R) •• Knowledge of Java •• Outstanding analytical and problem-solving skills (financial modeling) •• Advanced Excel •• Prior experience in a customer- or client-facing role This role is heavily centered toward it and coding, but because it’s a businessfacing role, there is slight dependency of analysis and problem solving which are very much part of financial modeling. Expect these types of hybrid roles to be common in the future as job roles begin to move across skill domains.

Commercial and business possible job specification Financial modeling roles have already begun to move toward more commercial titles. As modeling becomes more accepted as a career path, expect the cross to become more pronounced. The job specification would look something like this: •• Provide advice, capital raising, derivatives, and financial strategy. •• Lead project workstreams. •• Develop new business through building client relationships. •• Have a direct relationship with clients while leading and engagement.

The Handbook of Financial Modeling •• Be responsible for presenting financial models to clients and internally. •• Create and maintain documentation (requirements, user manuals). Requirements •• College or university degree in finance, business administration, or something similar •• Professional membership (ACA, ACCA, CFA, or something similar) •• Be able to build models from scratch •• Advanced experience technologies (Excel, VBA) •• Preferable experience in project finance, debt models, BPO outsource bids, service pricing models •• Minimum of 7 years in financial modeling This role is somewhat available today in the professional services firms. However, I expect in time it will move to be a general modeling role across most businesses and will become the most prevalent financial modeling role. Notice how such a role requires a lead time of 7 years of experience. This experience is not unusual for commercial heavy roles.

Conclusion This chapter is a walk into the future to see what financial modelers can expect from their career. Although there is some speculation on some aspects of these roles, most of the prediction is based on sound experience from the movements in industry. In Chapter 17, we will be using a case study of a reallife company to explore just how they are going to transition their modelers in the future.

7

CHAPTER

2 Types of Financial Models Often when training financial modeling candidates, I am asked to describe the types of financial models. There will always be someone in the training group who will point out a model type that I have not heard about. This is hardly surprising because in actual fact, there are hundreds of types of models because a model can be whatever you want it to be. All is not lost, though, as there are a number of model types that are used most frequently in organizations. These types of models have either come out of some form of industry standard or, in many cases, have been established by the financial modeling community as best practice models. In this chapter, we will look at a few of these models and briefly summarize the model features, which are ·· Financial statements ·· Consolidation ·· Mergers and acquisition (M&A)

© Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6_2

10

Chapter 2 | Types of Financial Models ·· Leveraged buyout (LBO) ·· Budget and forecast models ·· Discounted cash flow (DCF) This is not definitive of all financial types; however, it is safe to say these models cover more than 50% of financial models.

Financial statement models The financial statement model is an output model which has the income statement, the cash flow, and the balance sheet linked together and dynamically driven by the inputs. This model, while seemingly simple, does require a sound understanding of accounting concepts because of the relationship between the three statements.

Understanding the financial statements There are several pitfalls to look for while building a financial statement model. The most damaging of the pitfalls is to understand the difference between cash basis and accrual basis.

Cash vs. accrual In cash basis accounting, we record revenue in the accounts when we receive the cash. We also record expenses incurred when we pay for them. This means that on a cash basis system, there is no need to have accounts receivable (debtors) or accounts payable (creditors). In the accrual basis, all revenues and expenses are recorded at the time when they accrue (not when they are paid or received). This means we will have accounts receivable and accounts payable. For example, imagine a storage company provide storing facility in January for its client. The company then sends an invoice in February to the client for January storage of $300 to be paid within 30 days. The service has been performed (January storage), but the cash ($300) will be received between now and 30 days. The cash basis there is zero recorded for revenue in January. In accrual basis, the accounts would show revenue for January as $300. It’s clear to see the accrual basis gives a realistic view of revenue and expense during the time periods that the services were performed. This concept of accrual basis has far-reaching implications for business and is subject to strict accounting rules. (We will cover these concepts in Chapter 9.)

The Handbook of Financial Modeling

What about cash flow? The accrual basis does also have a downside. Due to the recording of movements based on when they are performed and not when cash is moved, the basis does not give a company a realistic view of its cash flow. Keep in mind that for a business, cash flow is the key to surviving. This means when preparing accounts of an accrual basis, steps must be taken to create a cash flow statement outside of the accrual system. All transactions related to revenues, costs, assets, and liabilities are reflected in the accounts for the period in which actual receipts or actual payments are made.

 ow the income statement, cash flow, and balance H sheet are linked Where the accounting knowledge comes into play is the understanding of how the three statements are linked. I will give a high-level view of this linkage, but I won’t explore the deeper accounting rationale.

Net earnings Firstly, we need to understand the links between the income statement and balance sheet. The key here is that the result of the income statement, which is called the net earnings, net income, or net loss, must be reflected in the balance sheet as part of shareholders or owners’ equity. Figure 2-1 shows how the income statement and balance sheet sit next to each other. See how the connection between the net earnings in the income statement is pulled into the retained earnings of the balance sheet.

11

12

Chapter 2 | Types of Financial Models

Figure 2-1.  The income statement is linked with the net earnings to retained earnings

In essence, this is the amount of money that can be distributed to the owners of the business. For now, we won’t worry how the technical modeling of the net earnings and retained earnings is accomplished; we will be covering the modeling techniques through the book.

Depreciation and amortization The next step is to link to the cash flow between the income statement and the balance sheet. Depreciation and amortization are capitalized items. This means they are not actual cash movements, but they are accounting adjustments. Therefore, we need to get them pulled out of cash flow calculations to get to our real cash amount as depicted in Figure 2-2.

The Handbook of Financial Modeling

Figure 2-2.  Depreciation from the balance sheet is reversed in the cash flow

You can see how in order to reflect the pulling out, the value type of the depreciation has been changed from negative in the income statement to a positive in the cash flow. Accountants will understand this as balancing between debit and credit in order to maintain a balanced set of accounts.

The working capital The working capital are those elements of the balance sheet that fit into the current assets and the current liabilities. They tend to be elements that are in constant change day to day such as bank account, cash, and inventory accounts payables and receivables. The cash flow and balance sheet are linked through working capital. We need to assess the movements (changes) in the balance sheet working capital between the previous period and the current period. This movement must be reflected in the cash flow in the current period as shown in Figure 2-3.

13

14

Chapter 2 | Types of Financial Models

Figure 2-3.  The working capital movements are reflected in the cash flow

There are other linkages between income statement and cash flow concerning debt, interest, and taxation. I won’t go through these as they require complex accounting which is not part of this book. However, the concept of how to treat the debt, tax, and interest is similar to how we treated the working capital. The main difference being these elements also have varying schedules that must be applied based on set terms of conditions.

Getting the cash Once the elements of retained earning, working capital, and any debt, interest, and taxation are dealt with, We should then have an opening and closing cash for each period. It is that closing cash that is then used in the balance sheet cash or bank account shown in Figure 2-4.

The Handbook of Financial Modeling

Figure 2-4.  The cash from the cash flow is placed into the bank account

There is a further technical problem that occurs when you link your closing cash to the balance sheet in that you will create a circular reference in the model. It is something you should avoid doing at all costs, as it creates a ripple effect in the model and is uncontrollable. The circular reference is caused because in order to get to your cash, you need to know your working capital, which has cash in it. Once you have your cash, you put this back into your working capital. The key to building a statement model is to keep a strict adherence to the structure. Financial statement models require a methodical and disciplined approach or else they will fail. A typical sign of a failed financial statement model is a modeler’s nightmare, the out-of-balance balance sheet. Trust me, you don’t want to be in a position of trying to correct an out-of-balance balance sheet.

Consolidation model Consolidation models are in their basic form a set of models created within their own worksheet tab and then grouped together to form one combined output. A feature of a good consolidation model is all the worksheets are structured in exactly the same manner with the same look and feel. The final group worksheet will also look the same.

15

16

Chapter 2 | Types of Financial Models The individual worksheets can represent a cost center, department, product, or service or even a company. What is important is that all the worksheets have some linkage so that a change in one will be reflected in the final group worksheet. Figure  2-5 shows a typical consolidation model with four companies and the consolidation.

Figure 2-5.  The consolidation of four companies

The consolidation is for the four company tabs. In Figure 2-6 and Figure 2-7, we can see Company1 and Company2. Notice both these worksheets look exactly the same structurally and are also the same as the consolidation in Figure 2-5.

The Handbook of Financial Modeling

Figure 2-6. Company1

Figure 2-7. Company2

There are a number of modeling pitfalls to look out for when building consolidation models that must be thought through before the model is developed.

17

18

Chapter 2 | Types of Financial Models

Watch the file size Consolidating several worksheets can create a bulky excel file. Excel processing engine diminishes exponentially with the increase in file size. From experience, file sizes greater than 10MB can start to cause problems including lagging calculations, corrupt file, lack of memory, and others. This is whether the skills of the modeler will come into their own, in using techniques with formula construction to limit the file size. We will cover more about how to use the right combinations of formula in Chapter 11.

Complex links There is a temptation when building a consolidation model to try and emulate the structure of the companies in exactly the same way they operate. Some thought will need to be applied because it’s fraught with problems. Let’s take an example of creating a consolidation of the three financial statements income statement, cash flow statement, and balance sheet. You can consolidate the income statements easily by just adding up of the income statement worksheet tabs. The problem starts when you try to consolidate the cash flow. The difficulty is how to take the closing cash and net earnings from individual companies into one consolidation, when there are also intercompany transfers involved. This situation does occur, and it will cause the model to become complex and confusing. As a rule, I advise that when developing consolidations, only segment the operational parts (revenue and cost). The cash flow and balance sheet should be created just once treating all companies as one and consolidated.

Be clear about the outputs Another issue with consolidated models is that once a model has been built and completed, the sponsor then decides they need more detailed balance sheet information at a company-by-company level, considering the balance sheet has been built at one consolidation. For instance, the consolidated model may show the working capital as being £1m. However, with five companies, the sponsor decides they want to see each company’s working capital so that they can see which company has a weaker cash flow. This is a nightmare scenario which can be avoided by getting confirmation from the sponsor at outset whether they need individual company balance sheets. If the sponsor does require an individual company detail, then you will need to create each company with income statement, cash flow, and balance sheet. Then, create an intercompany thread in each company and trace all the movements between the companies.

The Handbook of Financial Modeling Once completed, link all the companies together into a consolidation; the check will be that the intercompany movements will zero out.

Mergers and acquisition models Merger and acquisition models referred to as M&A models are specific purpose tools to evaluate the dilution of a merger between two or more companies, Company1 + Company2 = Merged Company, or an outright acquisition of one company and one or more target companies, Company1 = Company2 + Company 1. There can be some confusion as to whether there is a merger or acquisition because in the end, both processes produce one consolidated company. So what is the distinction? This distinction is based on the process used to get to the final consolidated company. It is a merger only when two or more companies come together through a mutual agreement to form a consolidated company, called an M&A process. It is an acquisition if one company proposes to acquire another company with cash or shares. Ironically in both a merger and acquisition, the process must be approved by shareholders of both the companies.

The M&A model nuisances M&A models can be complex, and as a result, developing such models requires a good level of experience of the M&A process. Not all modelers will be able to build M&A models, because not all modelers understand the requirements of modeling in M&A. However, a modeler with a good base understanding of financial modeling would be able to learn how to develop an M&A model relatively quickly. There are six key steps required for the modeler to develop an M&A model: 1. Create operational forecasts. 2. Collect all assumptions. 3. Create projections. 4. Combine the companies. 5. Make adjustments to the combined company. 6. Accredit the deal.

19

20

Chapter 2 | Types of Financial Models

Create operational forecast In the first instance, the modeler will need to use assumptions about the future operations of the merging companies. To do this, the modeler commences the development of the financial model with a detailed operational forecast of both the target and the acquiring companies as in Figures 2-8 to 2-11.

Figure 2-8.  The analysis of the acquiring company includes several operational schedules

Figure 2-9.  The cash flow forecast of the acquiring company is just one of the schedules prepared by the modeler

The Handbook of Financial Modeling

Figure 2-10.  The target company will also have forecast schedules prepared

Figure 2-11.  The income statement of the target company is just one of the schedules prepared by the modeler

21

22

Chapter 2 | Types of Financial Models The operational forecast should include the aspects of both companies such as ·· Income statement forecast ·· Cash flow forecast ·· Balance sheet forecast ·· Working capital forecast ·· Equity investments ·· Debt schedule ·· Depreciation and amortization schedule ·· Tax schedule ·· Outstanding shares

Build the assumptions Once the operational forecast schedules have been completed, a number of assumptions can be made and verified such as ·· Make any accounting adjustment to the forecast. ·· What is the actual purchase price of the target company? (business valuation) ·· Will the acquisition be based on cash, shares, or both? ·· What will be the number of shares issued to the target company? ·· What will be the cash paid to the target company? ·· When will the acquisition take place, the specific timing? ·· What are the incidentals related to the consolidation of the companies and can they be quantified in money terms? ·· Build a forecast of the target and acquired company based on these assumptions. ■■ Note  Valuations are performed by both the acquiring and target companies, using some well-established valuation methodologies such as the weighted average cost of capital (WACC), Perform terminal value and discounted cash flow model. These methodologies are quite technical and complex as they are models in their own right. This book will not go into any depth in these methodologies, but to say there is a great deal of information in the public domain about how to use these methodologies.

The Handbook of Financial Modeling The modeler creates a worksheet that captures all the facets of the assumptions which will be used as inputs into the M&A model as in Figure 2-12.

Figure 2-12.  The assumptions are collected and placed in an assumption worksheet as inputs

Notice in Figure  2-12 there is a scenario scheme incorporated into the assumptions. In this case, there are nine different scenarios available. Having scenarios is not a mandatory requirement for M&A models; however, financial modelers should always be looking to add flexibility to models they develop. Allows users of the model to make a “what-if” decision.

Projections By linking the operational forecast schedules with assumptions (inputs), the model will then be capable of delivering projects from various scenarios. This is where the modeler must use their skill to make sure all the variables in the operational forecast are linked to the requisite assumptions. There is a real danger of transparency that can happen in M&A models. Let me explain. Once a modeler has developed the operational forecast and linked them to the assumptions, every time an assumption changes, there will be a center change in the forecasts. The issue is how will the eventual model user deduce the exact effect of each assumption if the forecasts are always shifting?

23

24

Chapter 2 | Types of Financial Models The way around this problem is through the model structure. The modeler should create a duplicate set of operational forecast, but this duplicate will remain fixed. (It won’t be linked to the assumptions.) The duplicate forecast will effectively be the base case, that is, the original premise of the M&A forecast. This way, every time the assumptions are changed, the forecasts will move, and a comparison can be made between the base case. Accountants call this variance analysis. By implementing variance analysis into the M&A model, the modeler can give the model user a powerful tool to quickly assess which assumptions are key to the merger.

Combine the acquirer and the target companies The modeler will create a stage in the M&A model that combines the acquirer and the target companies. Essentially this is combining the balance sheets of the companies and applying any accounting adjustments or regulatory fixes such as valuing of goodwill, value shares and options, and other adjustments. In order to create the desired combined merged company schedule forecast, the modeler must undertake an exercise in assimilating synergies between the joining companies. Synergy will arise when the value of the combined companies is higher than the combined companies before the merger or acquisition. It’s a little tricky to understand, but let’s assume the value of the acquiring company before the merger was $100m and the target company value before was $90m. Once they have been combined, the value of the new company is $300m. Then, the synergy is $300m - $190m = synergy $110m. Figure 2-13 shows the typical synergy calculations in the income statement.

The Handbook of Financial Modeling

Figure 2-13.  The calculation of synergies is performed

Figure 2-14.  All the forecast schedules are completed in the pro forma

Once the synergy is exposed, then the final combined forecasts can be completed called the pro forma in Figure  2-14. The synergies can now be reflected in all the pro forma model calculation like the income statement in Figure 2-15.

25

26

Chapter 2 | Types of Financial Models

Figure 2-15.  The income statement in the pro forma

Leveraged buyout model (LBO) A leveraged buyout is where a company is acquired using debt as the significant source for financing. In real-life transactions, LBO tends to occur when private equity companies borrow up to 80% of their purchase price from lenders. At this stage you may think why would any company borrow so much and add additional risk to the company. There are several reasons why a company would deem it useful to have a high borrowing mainly based on how they see themselves growing in the future and the returns they can earn for the equity partner. I won’t delve into the ins and outs of why leverage buyout as that often a subjective matter. You are most likely to come across LBO models in investment banking and in private equity environments. The perception in the finance world is LBO models are complex due to the waterfall effect of different debt schedules. For the modeler there is nothing to fear with LBO models. If you have a firm grasp of the financial statement modeling and are willing to take on best practice financial modeling, then you are 90% there with being able to build LBO models. To simplify the LBO model development, think of it as having five steps: ·· Collect the purchase price assumptions. ·· Create sources and uses list.

The Handbook of Financial Modeling ·· Create financial projections. ·· Transaction balance sheet adjustments. ·· Debt and interest schedule. ·· Credit metrics. ·· Calculate DCF and IRR on initial investment.

Collect purchase price assumptions The assumptions relating to aspects such as debit interest level and operating scenarios should be gathered and placed in assumptions worksheets. Figure 2-16 shows a typical model assumptions worksheet. These assumptions will become the working inputs for the model.

Figure 2-16.  The LBO model assumption worksheet

Create sources and uses list The sources and uses list is much as it sounds and is part of the assumptions. This is a collection of where the debt is coming from (which institution) and the terms as in Figure 2-17.

27

28

Chapter 2 | Types of Financial Models

Figure 2-17.  The sources and uses list in the assumptions

The sources are then matched against how the debt will be used. The best way to create the complete list is to first list out all sources and then list all known uses for the funds. Then, lastly once you have the two lists, begin to match the sources and the uses, possible by using some number coding.

Create financial projections Once all the assumptions have been gathered, it’s time to construct an income statement, cash flow, and balance sheet. These statements should be forecast for at least five years into the future and are accompanied with schedules for amortization, depreciation, working capital, tax, debt, interest rates, and outstanding shares as in Figure  2-18. Each of the financial forecasts will be created at a detailed level and must project at least five years into the future like the cash flow in Figure 2-19.

The Handbook of Financial Modeling

Figure 2-18.  The list of schedules and forecasts in the LBO model

Figure 2-19.  The forecast cash flow

29

30

Chapter 2 | Types of Financial Models

Transaction balance sheet adjustments This is where LBO modeling can be a little tricky. Prior to completing all the financial forecast, the modeler should prepare a pro forma balance sheet which is independent of the forecast. The pro forma balance sheet shows all the balance sheet items after the change in capital structure (recapitalization). In effect, this pro forma balance sheet is a mirror into the future giving insight of the total adjustments and capital structure of the company after the LBO transaction is completed. Figure 2-20 is the closing pro forma balance sheet which is then modeled to flow back up to the balance sheet in the forecasts.

Figure 2-20.  The pro forma transaction balance sheet which flows into the forecast balance sheet

Debt and interest schedule The debt and interest schedule (Figure 2-21) provides the details of all layers of debt and interest payments. This detail will include the line of credit, the loan terms, and any subordinate debt. This schedule is modeled to link into the balance sheet in the forecasts.

The Handbook of Financial Modeling

Figure 2-21.  LBO model debt schedule

Credit metrics The metrics on the companies’ credit (Figure  2-22) are to assess how the company can service its debt obligations (both principal and interest). There are key metrics to model which include ·· Debt/EBITDA ·· Interest coverage ratio ·· Fixed charges ratio

31

32

Chapter 2 | Types of Financial Models

Figure 2-22.  Creating a credit metrics is critical to the model

Calculate DCF and IRR on initial investment A discounted cash flow model is built into the forecast data running from the cash flow. Free cash flows are calculated by every type of investor who will then have a calculation for internal rate of return (IRR) and net present value (NPV). Figures 2-23 and 2-24 show how the NPV and IRR calculations could look like.

Figure 2-23.  The discounted cash flow is calculated on each investor type

The Handbook of Financial Modeling

Figure 2-24.  The internal rate of return is calculated on each investor type

Exit The last step in the LBO model is to get the company’s exit value. There is a specific calculation which draws on the forecasts and metrics which looks at five years EBITDA of the company and subtracts the debt to give the exit value. The exit value is the culmination of all the calculations in the model, and therefore without completing each of the steps, the exit value cannot be calculated.

Budget and forecast models Budget and forecast models are the most widely built and used types of financial model. When people think of spreadsheet models, most likely they have budget or forecast model in mind. These types of models are used widely in the financial environment in particular management accounting and financial planning and analysis. When I am asked by someone where they could learn to build financial models, I always advise the best starting point is to build a budget or forecast model. The reason is that these models are relatively simple to build and this is where a modeler can best explore and learn best practice modeling.

33

34

Chapter 2 | Types of Financial Models There are five activities to a budget forecast model: ·· Establish the historical data. ·· Create a template for assumptions. ·· Run assumptions on the historical data. ·· Develop the outputs. ·· Compare. Ironically these budget and forecast models although relatively easy to create tend to be built incorrectly. There is a presumption that any model built in excel is a financial model. We will explore further in Chapter 3 the key factors that make a model into a financial model.

Establish the historical data To have a fully functioning budget or forecast model, the modeler must have some originating data as base. The data could be a set of assumptions or more commonly a set of historical financial data. Figure  2-25 is typical of historical data that is placed within a worksheet and can then be used for further analysis.

Figure 2-25.  The historical data is placed into a worksheet

The Handbook of Financial Modeling Depending on the requirements of the model and the skill of the financial modeler, the historical data can also be imported from an external data sources into the worksheet automatically using inbuilt important queries in excel.

Create a template for the assumptions The assumptions are items of information that have been implied by the final user of the model but can also be manipulated and changed over time. Think of these as variables or key drivers to the outputs. Figure 2-26 shows groups of assumptions which will become inputs to the model.

Figure 2-26.  The assumptions are the inputs of the model

Run assumptions against the historical data The modeler will need to create a calculation or working worksheet that takes the assumptions uses that to act on the historical data. This is where the technical skill of the modeler in understanding how the assumptions can be evaluated comes into play. In Figure 2-27, the working worksheet is used to create a formula that will drive the historical data with the assumptions into the outputs.

35

36

Chapter 2 | Types of Financial Models

Figure 2-27.  The calculations can be very detailed

Develop the outputs Although the outputs are shown as being developed after the assumptions in this example, in reality the modeler would actually develop the outputs first, and before creating any inputs as in Figure  2-28. We will look at why it’s important to have outputs first in Chapter 3. Outputs can take several forms, including a dashboard (Figure 2-28) or data table.

Figure 2-28.  The outputs are created as dashboard

The Handbook of Financial Modeling

Compare Every budget and forecast model must have a capability to compare the historical data against the assumed data driven by the assumptions. This is a variance analysis which will give the user an insight into how the assumptions drive the model and to isolate which assumptions are the significant (key) drivers to the company as in Figures 2-29 and 2-30.

Figure 2-29.  The extrapolation of historical data driven with the assumptions

Figure 2-30.  A view of the variances in the data driven by assumptions

37

38

Chapter 2 | Types of Financial Models

Conclusion This chapter has described the various financial models in common use today and has given some insights into how these models are put together. The chapter is heavy and quite technical, so if you have been able to stick through to the end, you will have a very good grounding for the following chapters in this book. It is imperative that a modeler has a good understanding and can recognize reasonably quickly the type of model required to build the key components of the model. Having that understanding will help the modeler in the future to build the right model for the situation they are presented with.

CHAPTER

3 Review of Best Practices for Financial Modelers Across most organizations, there is a use of spreadsheet (mainly using Microsoft Excel) to assist with decision-making. The estimates bandied around in the Web suggest that there are hundreds of millions of active users using spreadsheets daily. Now, that is a whole lot of spreadsheet being created and used every single day. So how many financial models are out there being used in organization? On the face of it, this is a ridiculous question, because it’s virtually impossible for anyone to calculate. Perhaps then the problem is actually within the question. We really should be asking: what proportion of spreadsheets used today are financial models?

© Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6_3

40

Chapter 3 | Review of Best Practices for Financial Modelers I would hazard a guess (based purely on my experience so this is not an empirical observation) that the proportion of spreadsheets which are financial models is no greater than 5% of all models. The number of financial models against spreadsheets is low for several reasons because it’s not everyone who needs a financial model. Often in organization all that is required is a spreadsheet to provide tables or show data or just some simple math or create a flow diagram. So let’s be clear that a spreadsheet does not have to be a financial model. Another reason why the proportion of financial models to spreadsheets is low is that most potential financial models are not built by financial modelers. Often, they are built by someone who has a good technical background in Excel or has a financial background. Don’t get me wrong, I am not diminishing the work of anyone who uses spreadsheets; in fact, I am all for people developing financials in spreadsheets. However, suffice to say that building a financial model is more than having a technical Excel or financial background. Therefore, there are people who believe they build financial models but that might not be so. This is a critical chapter toward understanding and becoming a financial modeler. We should not underestimate the impact of best practices on financial models. Best practice in financial modeling is like a ship without a sail; it might get you to where you want, but at what cost? For anyone wanting to build financial models and become a financial modeler, best practices are not an option. We will look at the most critical financial modeling best practices and describe why they should be adhered to and in some cases look at potential issues when they are not followed. The following list while not being a comprehensive list does have the most critical best practices for financial modeling: ·· Workbook assumptions. ·· Workbook cover. ·· Workbook table of contents. ·· Workbook styles. ·· Worksheet classification. ·· Worksheet titles. ·· Worksheet documentation. ·· Worksheet error checking.

The Handbook of Financial Modeling ·· Keep constituents separate. ·· Reduce implicit assumptions to minimum. ·· No constants within formula. ·· Inputs drive the model, not calculations. ·· One input on assumption. ·· Specify the units of measurement. ·· Logic flow of calculations. ·· Avoid circularities. ·· Consistent formula across rows. ·· Do not mix time periods. ·· Avoid long and complex formula constructions. ·· Merge cells on data. ·· Avoid fonts with the same color background. ·· Always include visible error checking. ·· Avoid using VBA on critical calculations. These lists of best practices are described in the following sections.

Workbook assumptions Every model will have some assumptions behind it. There may not be many but there will some. For example, even something like “We need the model to project this year’s financial result” is an assumption. The assumption here is that the model must be built to reflect years, and this year is the focus; however, what happens next year? Assumptions should be collected and listed in an assumption worksheet which should include ·· The date when the assumption was modeled. ·· The description of the assumption. ·· The source of that assumption. ·· A reference for the assumption. ·· A verification as to whether that assumption is included as an input. ·· Is this a base assumption or sensitivity assumption?

41

42

Chapter 3 | Review of Best Practices for Financial Modelers Reason why ·· The assumption communication information of the environment and the thinking that was available at the time when the model was being developed. ·· The assumption allows flexibility to exist in the model and increases the model’s reuse value. ·· The assumptions are the precursor to the inputs in the model. ·· Assumptions give the model a wider appeal to users because the knowledge is not locked in the modeler. Issues of omission ·· The purpose of the model will not be clear, which means the model could be used for wrong reasons. ·· The model outputs are meaningless as there is no basis as to why they are what they are. ·· There is an ability to stress test the model to understand the effects of changes if assumptions are not available. ·· The model is no longer adaptable to changes in the business environment.

Workbook cover The cover should by design give a summary of the model. The cover is a worksheet to start the model. I find so many financial models without a cover sheet which is a sign that the modeler who built the model is not versed in modeling practices as in Figure 3-1.

The Handbook of Financial Modeling

Figure 3-1.  The cover sheet should give contacts and the purpose of the model

Reason why ·· Cover sheet is the means to inform users of the model about who built the model, why, when, and who sponsored the model. ·· The model has a starting point, and there it allows the users to orientate themselves with navigation through the model after its open. ·· The cover sheet can be a form of access control, to only allow authorized users into the model and protect sensitive information.

Workbook table of contents When opening and Excel workbook, we can see that navigation is based on the worksheet tabs at the bottom of the spreadsheet. However (in Excel 2010 and onward), there are over 16 thousand columns and over a 1 million rows. Although, unlikely, it is possible to have a worksheet that utilizes most of the rows and columns, how daunting is that? For this reason, it is essential that a model has a more detailed and defined means of navigation other than the worksheet tabs. There should be a way to get to pertinent sections of any model. For instance, if the model contains several financial schedules all built in one worksheet, we need a table of contents to easily select each individual schedule.

43

44

Chapter 3 | Review of Best Practices for Financial Modelers In modeling a table of contents in a list (not always in alphabetical order), hyperlink into worksheets and cells. Remember to also include a link in each worksheet to return to the table of contents. Figure 3-2 is an example of such a table.

Figure 3-2.  A table of contents provides navigation into the model

Reasons why ·· It makes the model user-friendly. ·· The modeler can create navigation. ·· The modeler can control the user’s experience. ·· It is a means to orientate the model user. Issues of omission ·· There is a lack of understanding where vital parts of the model are located. ·· The user may not understand where the inputs and outputs are located. ·· There is no natural flow through the model.

The Handbook of Financial Modeling

Workbook styles The model styles are the method by which the financial modeler can inform the eventual users of the conventions used in the model. Let’s face it, every modeler will have their own way of modeling, for instance, how they create formula or how they perform error checking. Any user of model will be unaware of the modeler’s convention unless they have been given instruction. This is where the style sheet comes into play. A modeler should never neglect the style sheet no matter how small the model. Leaving out a style sheet gives little consideration to the eventual model user. Figure 3-3 is an example of a model style sheet.

Figure 3-3.  The styles give the users an idea of the conventions used in the model

Reasons why ·· It helps to create a consistent approach to the entire model. ·· It instructs the users as to where they can interact with the model. ·· It gives direction to the model users. ·· It is part of the model documentation.

45

46

Chapter 3 | Review of Best Practices for Financial Modelers Issues of omission ·· Users of the model will be confused by the color schemes without understanding why. ·· The model will be inconsistent and will lack a professional approach.

Worksheet classification The purpose of the worksheet should be visually identifiable. The worksheets should be based on one of three types, inputs, calculations, or outputs. All worksheets in the model should conform to one of the three options. Reasons why Every worksheet in the model should serve a purpose toward the ultimate goal. The model user will need to understand which worksheets are interactive and which ones are for outputs. It gives a structure to the model. It allows for developing the model in modular method which means a model can be developed by more than one modeler at the same time. Issues of omission ·· It will not be clear how each of the worksheets is connected and how the overall model leads to the outputs. Any update or adaptability of the model is restricted. ·· The ability to audit or review the model is severally hampered and will result in a negative audit certificate. That is not good for a model. ·· Model structure and discipline of the modeler are not apparent.

Worksheet titles The top of every worksheet needs to have a number of details including the model name, the name of the worksheet, and the file name. Although optional (see Figure 3-4) for financial models developed for a client, it’s good modeling to have the client name in the titles.

The Handbook of Financial Modeling

Figure 3-4.  The top left of the worksheet has the titles

Reasons why ·· It adds consistency and structure to the model as every worksheet will have the same look and fell in its titles. ·· It gives a quick identification of the worksheet and its placement within the model. Issues of omission ·· Loss of consistency will cause confusion in the users, who will not know if a worksheet is critical to the model. ·· It’s difficult to control the flow of the model without knowing the details of each worksheet. ·· Documentation on a sheet-by-sheet basis is lost.

Worksheet documentation In financial models, there is often confusion as to the meaning of documentation and what is the difference with a user guide. So let’s clear that up. The user guide is a media that provides instructions on how to use the model. Documentation is a material that gives an account of specifics in the model. Documentation is really a recordkeeping of all the aspects of the model that are deemed too significant by the modeler.

47

48

Chapter 3 | Review of Best Practices for Financial Modelers To this end, financial models should always have documentation as in Figure 3-5, particularly if the model is expected to be used to provide critical decisions.

Figure 3-5.  The documentation is a worksheet recording every facet of the model

Any model that is delivered to a client should have documentation. Reasons why ·· Documentation is a way to stamp each part of the model and give an account of the impact to the overall model. ·· Documenting the model is useful to any modeler in the future who needs to update, expand, or rebuild the model. ·· By documenting the model, the user guide becomes far more easier to create and test. ·· Documentation is a vital part of the model audit and review. Issues of omission ·· Models that lack documentation quickly fall of use. That is because no one understands what the model does and how it does, so the model loses credibility.

The Handbook of Financial Modeling ·· On large models, documentation allows the modeler to build the model consistently and maintain the structure throughout the model. ·· It is virtually impossible to build a modular model with several modelers without documentation. ·· Without documentation, the process of testing the model against the requirements can be frustrating.

Worksheet error checking Error checks are indicators placed in individual worksheets to check the integrity of information entering a model. These seek out cells in worksheets where the information is expected to change or move such as the inputs. The checks are there to highlight the changes that have deviated from the expected norm. Error checks can be placed to look for logic changes, that is, Jan, feb mar, and jun, or numerical changes such 2 + 2 =5 and format changes where a date is expected but receives a text or when there is omission of information. A modeler should come from the angle that errors will creep into a model because model users will always find a way to introduce an error inadvertently. That means a good model will always have several checks at the worksheet level ready to give a signal to the model user whenever an error has occurred as in Figure 3-6.

Figure 3-6.  Financial model should always have an error check mechanism

49

50

Chapter 3 | Review of Best Practices for Financial Modelers Reasons why ·· Spreadsheets do not have inbuilt integrity checks; therefore, it’s for the modeler to make this. ·· The more checks there are, the more assurance a modeler can give for the outputs being correct. ·· Mistakes such as deleting rows or columns have been known to be made by model users; it’s imperative these are caught. ·· Balance sheets are particularly prone to errors causing an outbalance. The integrity of the whole model is lost by such a problem. Issues of omission ·· There will be errors in the model that are difficult to see even for the modeler; one error can invalidate a model. ·· Lack of error checks will make the model users uneasy about using the model. ·· Lack of error checks invalidates a financial model. The best practice focuses more on the techniques that the modelers use. They are no less important than the practices already covered; however, these practices are mandatory to a modeler. The practices shown are enshrined in financial modeling, and suffice to say modelers who cannot or do not use these tenets should question whether they are financial modelers.

Keep constituents separate Separating the inputs, calculations, and outputs is not an option, but a mandatory requirement for every financial modeler—this is possibly the single most quoted principle of financial modeling. There are clear reasons for these separations. Separating the modeling stages ensures that the number of errors that otherwise would have been made due to the user’s lack of understanding of the model can be cut down. Separating the inputs and outputs assists with auditing and tracking, which ultimately gives the model credibility as it provides transparency to outputs (the financial statements). The separation is essential and is an indicator that the model has been developed by someone who understands financial modeling. Being able to identify inputs of a spreadsheet is crucial for understanding the effect on the outputs, such as what the outputs are based on.

The Handbook of Financial Modeling It is also important that inputs can be used to perform “what-if” analysis on outputs. Models lack these separations due to lack of planning, and unfortunately for all who will use them, these models are very likely to have any number of acute errors. The main reason for this error rate is that the models have not been planned, designed, and built as financial models, nor have they been built by bona fide financial modelers. Here is a list of several ways to separate inputs from the calculations and outputs: ·· Use different colors: For example, use a yellow cell fill for inputs and a gray cell fill for calculations and outputs. This is usually suitable for very small models. ·· Use different areas of a single worksheet: For example, label an area “Inputs” at the top of the worksheet and “Calculations” below the inputs with the outputs below the calculations. This is usually suitable for relatively simple models. ·· Use different worksheets for the inputs, calculations, and outputs for medium and large models.

Reduce implicit assumptions to minimum During the model development, it’s very easy for the modeler to build assumptions into the structure of the model. For example, an assumption that we are using Euros as the currency is implicit. If the company expands its operations and starts to trade internationally in the future, that model will become redundant. A better way would be to model currency assumption with an explicit input to state the currency we are using in our outputs and even to show the conversion rate use for multiple currencies. For example, Figure  3-7 clearly shows the base currency is Euro and the outputs are using the same base currency (Euro).

51

52

Chapter 3 | Review of Best Practices for Financial Modelers

Figure 3-7.  The currency has been placed in the Constants (assumptions) worksheet

Notice there is also table to change the base currency and the ability to update currency rates. Thus such a model is flexible and because all the currency assumptions are explicit there will little room for confusion and costly mistakes.

No constants within a formula Never use constants inside formulas as they are a cause of major errors in models. A constant is a number which has been placed into a formula but is not tied to any assumption, and therefore even when the model undergoes changes, that formula will be fixed. You should use constants inside formulas only for very obvious things that never change, such as there being 12 months in a year. Any less straightforward constants warrant being separated out just to make clear that they exist. For example, if you want to find the difference between the costs in Department A and Department B and then convert the currency from US dollars to Euro, we could create a formula: =(Sum(DeptA) -Sum(DeptB)) x 1.05 The problem with this formula is that although we know that the 1.05 is the currency conversion rate, the model user won’t know. The number is a constant built into the formula, and should the currency conversion rate change to 1.07, this formula will still compute an incorrect difference.

The Handbook of Financial Modeling In this situation the best policy is to have a formula more like this: =(Sum(DeptA) -Sum(DeptB)) x Euro Then, we would make an assumption naming the Euro currency and defining the rate. It should be clear to the model user that we are using a Euro currency conversion. In Figure  3-8, the formula is used to set up the timelines for the months. Notice the name MinY used.

Figure 3-8.  The Formula bar shows MinY in calculations

This MinY is logged in the assumption (Figure 3-9) as the number of months in a year. So we could simply place a 12 instead, but that would create a constant, so we have made this an assumption.

53

54

Chapter 3 | Review of Best Practices for Financial Modelers

Figure 3-9.  The MinY is an assumption for months in the year

■■ Tip  Ironically, the way that constants are used in models is an indication as to the competency of the modeler. In general, a seasoned modeler will never place constants within a formula. Test it out for yourself if you have the opportunity to audit or view a financial model. Check for these constants in formulas and see how many you find; a sound model will contain a few, if any, constants in formula.

Inputs drive the model, not calculations The assumptions that you develop for the model should be guided by the final users’ thinking. It is very easy to base assumptions purely from the modeler’s point of view, which then leads to models that just don’t match what the final users expect. This is a frequent and potentially dangerous trap to fall in for many reasons, and it will invariably highlight weaknesses in the modeler’s understanding of the subject. Beware of this trap because it verges in the realm of professional negligence. When modeling, all assumptions must be traced and documented to the sponsor of the model. If there are many different types of assumptions, put them on the assumption’s sheet in separate small tables with their own headings. Create groups by using tables and labels for sections and subsections. A good approach is to apply indentation to make the logical hierarchy obvious or use grouping to separate headings. By modeling in this way, you will ensure that the user’s wishes are being considered.

The Handbook of Financial Modeling The diagram on assumptions in Figure 3-10 is a snapshot of a typical assumption register. But notice that for every assumption line, there is a requirement to provide an assumption owner and also a reference. While this may seem like overkill (particularly on a small model), my advice to any financial modeler is to never neglect the assumption register. This is your insurance policy against potential litigation should the assignment get out of your control and go off course.

Figure 3-10.  This is a snapshot of an assumption register. These registers should not be complex, but should supply the assumption and give the reference where it is used

One input to an assumption A very common mistake in models is that of creating multiple input assumptions for the same variable across the model. Duplicating input assumptions will require the user to change a given input in several places. Critically, if the user is unaware of all the changes that are required or forgets to make the changes, then the model will have some flawed inputs, dramatically increasing the risk of errors. The duplication of assumption inputs is common while building large complex models that have multiple modelers. To reduce the possibility of this type of problem, make sure the model documentation begins from the design stage and follows through the building and testing stages. Ideally, there should be a change control mechanism implemented during the building. If that is not yet possible, consider having a checklist with additions and changes made to the model. When there is more than one modeler, this checklist should be filled out by each modeler daily.

55

56

Chapter 3 | Review of Best Practices for Financial Modelers Duplicating assumption inputs is not restricted only to large models. It can also occur when there is a lack of planning on a complex model. I come across this situation regularly during model audits. This occurs because the focus has been on creating calculations prior to understanding the inputs. Then, as the complexity of the model becomes greater, the calculations become less adequate to handle the complexity. The modeler will then often lose track of which inputs interact with which calculations, and from then on, duplication can start to occur. From the model audit aspect, these types of errors are particularly difficult to find. It usually involves a process of elimination to get to the root cause, although fixing the errors is relatively simple. To avoid the mistake of duplicating assumptions, develop the practice of documenting the assumptions. Instead of just recording where the assumptions came from, also include where it is being used and where it is ending up. This step does mean that the model process will take longer, but the rewards far outweigh the potential heartache of having to recover an assumption input that has complex links. In Figure 3-11, the inputs are driving the calculations which are then driving the outputs. However, there is a problem. The inputs for project staff required per year (12) are also driving the number of months per year in calculations (12). Both of these assumptions are critical to the outputs, but because one input is driving two calculations, the output is flawed.

Figure 3-11.  The input is driving two different calculations

The Handbook of Financial Modeling We want to avoid anything that makes an input drive two different calculations as in Figure 3-12. We have just made sure the financial months in the year and the project staff required per year have been split into separate inputs. In addition, we have made sure in column C that calculations have a reference which can back to a single input.

Figure 3-12.  The inputs are driving separate calculations with referencing

By attaching a unique tag to every assumption, you should then use this tag reference in the model every time that assumption is used. Typically if you leave the first column blank, you can then use this to attach the ref tag. By applying this method, it then becomes quite simple to track where each assumption has ended up and how many times it has been used, which will also expose any duplication of an assumption.

Specify the units of measurement Model users should be able to understand the measurement unit for every input assumption. These units should be obvious to modelers, but they should not assume that everyone who sees the model over its lifetime will be equally informed. To avoid confusion and especially if a large number of units are involved, designate a separate column for measurement units. This step also helps to avoid errors with the conversion of units. You will be amazed how often measurements are omitted in models and become the cause of confusion. Typically, the measurements can range from anything to currencies, dates, volumes, or resources (usually full-time equivalents quoted as FTE).

57

58

Chapter 3 | Review of Best Practices for Financial Modelers

Logic flow of calculations Of all these best practices, the logic flow is perhaps the most difficult for modelers to understand and implement into their daily modeling. Formulas should take their parameters from rows above and columns to the left, as this makes the organization of the model more logical. Figure  3-13 illustrates how the worksheet data should reflect how a person can “read” the information as a book, without the need to skip pages and return.

Figure 3-13.  The logic flow is the data in worksheets

The concept of the flow is simple, but for some reason, it presents problems for many. For the modeler it comes down to planning and maintaining the discipline. If the worksheet has been planned, maintaining logic flow is really very simple. Logic flow is often a distinguishing feature between a financial modeler and someone who is very good with using Excel (Excel guru). Typically, Excel gurus do not worry about logic flow and therefore will create worksheets that can have several bidirectional data flows. If you look at a model developed by seasoned financial modeler, you can be 100% sure there will be a logic flow. There is a good reason why financial modeling best practice stipulates logic flow. It’s because if you avoid the concept of the logic flow, at some point in your modeling career, circularities will appear in the models you build.

The Handbook of Financial Modeling

Avoid circularities When we talk about circularities in financial models, what we mean is the appearance of a circular reference in an Excel workbook. Circular references are caused by a formula in cell that refers back to that same cell. Look at this example: ·· cell A1: =A2 x A3 ·· cell A2: =A4 x A5 ·· cell A3: =100 ·· cell A4: =200 ·· cell A5: =A1*300 Can you see where a circular reference is coming from? If you spotted, you would notice that cell A1 is =200 x A1 x 300 x 100, or A1 =600000000 x A1. Obviously, that is a circularity; A1 can’t be equal to a multiple of itself. The problem with circularities is that they are usually difficult to spot, and once they have been found, they require some major thinking from the modeler to reengineer. Nevertheless, always consider if it is possible to use a different approach or to change the input assumptions to avoid circularities, as they usually make models more difficult to use and update. Sometimes, it is preferable to create a macro that would copy and paste values to break the circularity rather than to allow circular references in Excel.

Consistent formula across rows When working with models, it is extremely important to use consistent formulas across the rows. When this principle is not followed, problems and errors will likely occur. For every calculation row, input a single formula and copy it across all the columns. Avoid using a different formula somewhere in the middle of a row. Doing so dramatically increases the risk of error at the development stage and also during any subsequent updates. If inconsistent formulas cannot be avoided, the relevant spreadsheet areas should be clearly marked with color and comments. Even so, such situations indicate a weakness in the model design.

59

60

Chapter 3 | Review of Best Practices for Financial Modelers The main concern with inconsistent rows is that users will assume they are consistent. At some point, they will end up trying to copy a formula across or down several cells at one go, thereby overwriting all the unique formulas you have created and plunging the model into generating errors. In Figure 3-14, the formula in cell C7 is the starting point for row 7.

Figure 3-14.  Left to right consistency can be maintained in the color shading

However, when moving across the row to cell D7, we would expect to see the same formula, but the formula has changed as in Figure  3-15. The consistency in row formula has been broken. We need to highlight this change to the model user, and we do that by changing the colors of the cell. Therefore, cells C7 and D7 have different colors in the cells.

The Handbook of Financial Modeling

Figure 3-15.  The formula is different in the cell

If the users have acquainted themselves with the model style sheet, they will understand the model color conventions and will know why the colors of the cells are different. Keeping left to right consistency is imperative to financial modeling. When you see the consistency omitted, it almost always signals that the modeler has chosen to jump straight into creating a formula without considering the design of the model. When performing model reviews or audits, this process is critical to look for and eliminate purely because an inconsistent formula is such a common cause for harm in financial models.

Do not mix time periods Often, the modeler is required to calculate short-term and long-term projections with different granularity. For example, a requirement might be to produce monthly forecasts for the first two years and yearly projections for a number of years after that. The temptation is sometimes to create monthly columns, followed by yearly columns (see Figure 3-16). Such a design decision must be avoided. You would either need to remember to change formulas in the middle of every row or need to make the formulas very complex to take care of the different period lengths correctly. (These types of situations are far too common on models not produced by financial modelers.) Both options would likely lead to problems over the model lifetime because it will become very difficult to create totals without making errors.

61

62

Chapter 3 | Review of Best Practices for Financial Modelers

Figure 3-16.  The dates and timescales have been mixed from months to years

My recommended approach is to build the entire model using the smallest required granularity (i.e., monthly in the case of Figure 3-16). You can always aggregate monthly columns into annual ones on a separate summary sheet.

Avoid long and complex formula constructions Among some Excel gurus and modelers, there is an unwritten rule that creating complex and long formula is in some way clever. Writing long and complex formulas that nobody can understand is not clever, but the product’s bad modeling practice. Try to instead split complex calculations into smaller pieces and utilize as many rows as required. Usually, the more separate calculations you use, the easier it will be to follow and understand the model. With this format, more logical elements will be labeled, and the resulting formulas will be much simpler.

Merge cells on data Excel is foremost a spreadsheet, and its power is in how the application deals with data. In modeling never use the formatting tool to merge two cells together if they contain data that will be performed by a formula. Have a look at Figure 3-17; the cell on row 7 has been merged into columns C and D.  Notice the Formula bar shows the data as cell C7, so what has happened to cell C8?

The Handbook of Financial Modeling

Figure 3-17.  Merged cells are always problematic of formula driving cells

That is the problem with merged cells; they produce uncertainty as to the target cell. In short, they not only confuse the model user, but they cause inconsistencies in the structure of calculations. If you feel you have to merge a data cell, don’t do it; look for another way around by adding either another column or row as a filler.

Avoid fonts with same color background I have witnessed models where the modeler has used the same color shade for the fonts as the background on specific cells. There can be a number of reasons for this, but the most worrying is that the modeler wanted to somehow hide a fudge from the model user. A fudge is a number or piece of data that is artificially added in order to force a formula to give a predicted outcome. As modeler you should never entertain using a fudge, as they send negative message about your modeling ability and further damage the impression others will have on your integrity. Auditors hate seeing fudges because they generally lead to some very unsavory outcomes. Needless to say, never use the same font color as the background in any models. Avoid getting into a habit of hiding information, and if you feel you need to add an artificial number to force the model to give a predicted outcome, then place it in the assumptions with a note and drive that from the inputs.

63

64

Chapter 3 | Review of Best Practices for Financial Modelers

Avoid using VBA on critical calculations VBA is the Microsoft scripting language that is inbuilt into all Microsoft Office applications. VBA is powerful and yet relatively easy to learn at a basic level. Here lies the problem. Almost any Excel user can create VBA using the VBA recorder or writing their own; however, there are a very few modelers who are capable of writing fully fledged strict VBA code with error trapping. If you write VBA code in a model, use the model to add functionality such as printing, giving alert messages, or even sending an email. Avoid creating VBA code that acts specifically on data, unless you are really sure about your VBA skills. The problem is if you don’t write robust VBA code, then the Lovely VBA routine you wrote in the merger and acquisition model will one day go wrong. It could go wrong in several ways, but the worst is no one knows it has gone wrong because the code has somehow not provided a message. This is not a good scenario for the modeler, and I can only say that in this situation, you better have some serious professional indemnity insurance.

Conclusion This is a definitive chapter because by introducing financial modeling best practices, the chapter brings you the first step to distinguish a financial modeler. Those who don’t build financial models don’t use best practice; financial modelers always use best practice. There is something for you to take home. If you find yourself as the user or reviewer of a model and the model developer has to describe how their model is built to best practice, the chances are it’s not. Best practice models don’t need to sell, and after reading this chapter, you will be able to spot a best practice model the moment you open it.

CHAPTER

4 The Modeling Life Cycle Explained Often, a financial modeler will be engaged by a client to deliver a financial model by a given date. Typically, these are the kinds of assignments taken by freelance financial modelers. The modeler is responsible for not just delivering the model but managing the engagement with the client and also managing the project. This chapter introduces the financial modeling life cycle to manage the client engagement and delivery of a financial model. Following the processes discussed in this chapter will ensure successful delivery of the model. This modeling life cycle is a complete end-to-end process as in Figure  4-1 based on the following activities: •• Feasibility •• Scope •• Requirements

© Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6_4

66

Chapter 4 | The Modeling Life Cycle Explained •• Specifications •• Documentation and timelines •• Model design •• Model build •• Model testing •• Model review •• Handover and maintenance Keep in mind that not all these activities are required for every financial modeling project (although 2–5 are the core activities that must be undertaken in every model) based on the size, the complexity, and the time constraints of the project.

The Handbook of Financial Modeling

Figure 4-1.  The financial modeling life cycle

The chapter discusses the lifecycle activities and addresses how each actively impacts the overall project delivery as in Figure 4-2.

67

68

Chapter 4 | The Modeling Life Cycle Explained

Figure 4-2.  The financial modeling project using the with the lifecycle activities

Feasibility The feasibility is a focused analysis of the financial modeling project which will analyze and evaluate the model project in light of whether it is technically feasible and is within a budgeted cost. The activity should produce a physical output such as document or presentation summarizing the following.

The draft modeling project scope This is used to define the business problem and/or opportunity to be addressed. The draft scope would define the parts of the client business affected either directly or indirectly by such a project, all project participants and end users, and the project sponsor. Should the feasibility get an approval, then the draft scope will be used in the modeling life cycle and given a greater detail. Ironically too many financial modeling projects do not have a well-defined project scope. Consequently, this leads to projects that wander in and out of business boundaries and an expanded scope after the project has commenced.

The current analysis This current analysis is an understanding of the current implementation, such of a system or financial model. The analysis will discover there is actually something wrong with the current system or model. Often, in modeling project, this analysis can suggest all that is required is a modification or update of the existing model. The strengths and weaknesses of the current system or model must also be identified (pros and cons).

The Handbook of Financial Modeling A very common problem with this analysis is when the modeler discovers the issues of the current model, there is a temptation to stop the analysis and fix the model at this time. Always keep in mind that this is a feasibility; the broader project has yet to commence, so all that is required is to document your findings at this stage.

Current requirements There is a conflict here because one of the tasks of financial modeling is the requirements gathering by the modeler, but the feasibility is prepared before. That said, it is vitally important that a top-level requirements gathering is performed specifically for the feasibility; this will not be as detailed or a deep as that taken during the requirements gathering stage.

The approach The approach is a recommended course of action (solution) to satisfy the top-level requirements. Here, various alternatives are considered along with an explanation as to why the preferred course of action is recommended. The considerations though are •• Does the recommended approach satisfy the requirements? •• Is it also a practical and viable solution?

Evaluation The evaluation should always examine the cost-effectiveness of the recommended course of action. In addition to the recommended solution, other alternatives are estimated in order to offer an economic comparison.

Review All of the preceding elements put into a feasibility study document or presentation and a review is conducted with project sponsor and relevant personnel. The outcome of the review is to substantiate the thoroughness and accuracy of the feasibility study, and to either approve or reject the project, or to revise the feasibility before any decision. For the modeler, an important activity is to make sure that approval of the project is signed by the sponsor and a commitment to support the project is given in writing. (Signatures carry a lot of weight later on as the project progresses.) Should the feasibility be rejected, the reasons for its rejection should be explained and attached to the document.

69

70

Chapter 4 | The Modeling Life Cycle Explained

Conclusion There is a very possibility that the modeler will enter into a client engagement after a feasibility has been completed and approved. Such a situation could be awkward as it means another person has provided the analysis of the solutions required and the requirements without input from the modeler. I advise any modeler in this situation to be unduly concerned, because you have the engagement and there will be an opportunity to create the project scope and requirements at the project commencement. This will be your opportunity to address any concerns or issues. There are some modelers who feel feasibilities are a waste of time and provide no tangible benefits. Just be aware that a feasibility study represents a commonsense approach to planning. On any modeling project, it is vitally important to have had a well-thought-out approach and plan to follow; otherwise, when things go wrong, the buck stops with you.

Scope The financial modeling project scope pertains to the work necessary to deliver a model and the deliverables. Each financial modeling problem should have a scope put together in a document that has had a review and approval by the stakeholders (model users) and sponsor.

Key concepts of a project scope The modeler should not be alarmed if the scope planning appears to be going back and forth. The best scope documents are almost always reiterative before a final agreed document is ready. The actual document should have a project scope baseline statement (what is in, what is out of scope) and a highlevel breakdown of the work activities. The important factor of the modeler at scope activity is to make sure all stakeholders must understand the scope baseline to minimize scope creep during project execution. It could be helpful when presenting a scope document to stakeholders and sponsors to have addressed the following points: •• Project justification (use the feasibility study if there is one) •• Project objectives •• Project scope description •• Project acceptance criteria

The Handbook of Financial Modeling •• Project constraints •• Project assumptions

Project justification It is critical that you justify why the project came to by describing the client’s business needs and how the model project addresses that need. Add to that the planned scope of work the modeler will perform. This is also an opportunity to add how the modeling project could be affected by any other activities you can foresee happening in the client business.

Project scope objectives Objectives are statements describing what the project is trying to achieve. To assist with getting this objective right for the scope, think in terms of measurability. Write an objective in a way that can be measured so you can know when the project has been completed and delivered satisfactorily.

Product scope description The scope descriptions are the features and functions the modeler foresees in the final model.

Model acceptance criteria The acceptance criteria are a really critical part of the scope document. This section should state the standards required to satisfy the client quality expectations of the model to gain acceptance of the final model. Typically, this will come directly from the requirements gathering activities. Notice that the scope is before the requirements are gathered. In fact, you will find that because of the reiterative nature of the scoping; the requirements gathering tends to occur at the same time. From experience in modeling projects, the times of acceptance criteria tend to be •• Target dates •• Major functions •• Capacity, accuracy, and availability •• Repair times •• Development costs •• Running costs

71

72

Chapter 4 | The Modeling Life Cycle Explained

Project constraints A good advice is making sure the scope document clearly states project constraints. Constraints are anything that restricts the limit of the model, when the model is completed and how the model is produced. The most common constraints on modeling problems fall broadly into •• Technological: The sequence in which individual project activities must be completed •• Resource: Lack of necessary resources which may force parallel activities to be performed in sequence •• Physical: Contractual or environmental conditions You want to make sure all possible causes of delay in the project’s completion are highlighted in the scope. This is your indemnity, so make sure you put some real thought in it.

Project assumptions Assumptions are statements that we believe to be true and how the modeler will address uncertain information during conception, planning, and performance of the project. Assumptions are identified to add potential risk to a project even though they may turn out to be false. Assumptions can impact any part of a project life cycle, so it is important to document and analyze them.

Requirements Requirements gathering is absolutely critical to any project. Before reading further, I want you to think of when you have performed a structured requirements gathering exercise. Did you feel confident that you were doing it right? I ask the question because, for many of us, requirements gathering just sounds like common sense. Go out there, listen to stakeholders, and write down the list of things they want, right! There lies the problem because requirements gathering in modeling projects needs to be performed correctly as it drives the model testing. If the requirements are not well understood, the testing will not be accurate, and the final model will not be appropriately tested. The best way forward with requirements gathering is for modeler is: Step 1 Create a statement of requirement. This can be a document template with the following:

The Handbook of Financial Modeling •• A succinct requirement specification for management purposes. •• A statement of key objectives. •• A description of the environment in which the model will work. •• Background information and references to other relevant materials. •• Information on major design constraints. •• The contents of the statement of requirements should be stable with very infrequent changes. The statement is created by the modeler, but the details are filled in with the combination of stakeholders, project sponsor, the model end user, and the modeler. Step 2 Make sure you have cross-referenced the requirements in the statement of requirements with those in the high-level requirements in the feasibility and the scope to ensure there is no mismatch. Step 3 The last step is of greater importance. Once the statement of requirements is complete, the modeler must make sure all parties including stakeholders, project sponsor, and end user sign up to it. The modeler must then ensure all parties understand that this statement, and only this, is being delivered. There is a check that the modeler should make prior to getting the final sign-off. Pointers to modelers for a good requirements gathering Gathering requirements is not easy but is so critical to model projects. You get one chance to get it right, so failure is not really an option. Here are some pointers to any modeler on what to look for: •• Never assume you know what the stakeholder wants: There is nothing wrong with asking; always ask. •• Involve the model users from the start: The model users may not be clear at the outset of a project; do some investigation and locate them. •• You have a copy of the agreed scope of the project. •• Make all the requirements specific and measurable: This will help you to clarify when each requirement has been achieved in the model.

73

74

Chapter 4 | The Modeling Life Cycle Explained •• Be realistic about requirements: Don’t allow stakeholders to push you past something that is just not possible. •• Make each requirement have a timeline: You can have two requirements statements, your master copy and the official approved. In your master copy, place a timescale against every requirement (start date, end date); you can use this in your overall project plan. •• If there is any doubt about anything in the statement of requirements, go back to the stakeholders and sponsors to get clarity. •• Always playback your understanding of the requirements to the stakeholders and sponsor. •• There will be a temptation from stakeholders to discuss the model solution and the technology during the requirements gathering. Avoid any such conversations until the requirements are fully understood; otherwise, you could yourself having stakeholders with implied requirements. •• Do not start the project until the statement of requirements is understood and agreed by the stakeholders, sponsors, and model users. You may be tempted, but should you start too early, your requirements will continue to change and move throughout the project. Here are some pointers of mistakes that have arisen from financial model requirements in practice that you should always avoid: •• Basing a modeling solution on a cutting-edge technology unrelated to modeling only to discover it is just not possible to implement •• Not giving the priority requirements, such as “Mandatory,” “Optional,” and “Nice to have” •• Have not spent enough time consulting with the eventual model users •• Communicating you have the solution before knowing the requirements •• Lacking a clear understanding and making assumptions rather than clarifying

The Handbook of Financial Modeling

Conclusion of requirements A requirements gathering is about creating a clear, concise, and agreed set of customer requirements that allow you to provide precisely what the customer wants.

Specifications The specifications are the least understood stage of any modeling project because it tends to be more about the modeler’s experience. So, what is it? A specification is the discussion of a specific point or issue. The specification in a nutshell is the part where the modeler discusses how they will achieve each aspect of the requirements. When creating the requirements, the specification is developed alongside each requirement. The modeler will be looking at each requirement creating a template on how they will complete that requirement. In the modeling life cycle, the specification and requirements are reiterative, and thus as each requirement is developed, then a specification is also produced. The longer the requirements take to complete, then so does the specification. This will be the modeler working document on achieving the technical challenges of the modeling project. The specification document can end up being very detailed, defining each requirement implementation. For example, a specification document may list out all of the possible error states for a certain worksheet in the model, along with all of the error messages that should be displayed to the user. The specifications may describe the steps of any functional interaction, and the order in which they should be followed by the user. A requirements document, on the other hand, would state that the model must handle errors reasonably and effectively and provide explicit feedback to the users. A specification may not always be a document. Some modelers prefer to create diagrams or schematics of functional relationships or flow logic. In some cases, its possible specifications can also be in the form of a prototype of the model. Unlike the scope and requirements, the specification does not require approval or sign-off from the project client; it is purely a guide based on the modeler’s thinking for them to follow. Project specifications are much more important for determining the quality of the final model.

75

76

Chapter 4 | The Modeling Life Cycle Explained

Documentation and timelines Through the years, I have audited, reviewed, and updated several hundred financial models. The vast majority of those models have had no documentation, and of those that did have, the quality of the documentation has been poor. Documenting the financial modeling should never be just an option; it’s a critical activity for so many reasons. The foremost reason is that it brings the financial model to life. Documentation provides a means by which all aspects of the model development and its subsequent maintenance are available to whoever owns the model after the modeler has built it. Often, the documentation is confused with a user manual. Well the user manual is a subset of the overall model documentation. So, what is the documentation? The documentation is used to define the way the project is managed by any governance that surrounds the project and consists of several parts that make it up: •• The documentation has a project plan, and yes, the project plan is part of the documentation. •• The documentation contains statement logs that demonstrate the status of the project when active from various views such as risk. •• The documentation is a guide of the technical functionality and also a user guide on using the model.

Financial modeling project plan The project plan is the most important document that a modeler will create and maintain once the project begins. The plan is a forward-looking timeline that has a list of all activities during the project plan with the criticality and also dependencies on tasks and activities. It is used by the modeler to understand when the project is on track and when there have been slippages and to communicate to the project sponsor ahead of time.

Goal log I find it amazing how many financial modeling projects have no defined goals. Perhaps, this is because there is an assumption that the goal is in the scope, for example, a goal “deliver an overhead allocation model.”

The Handbook of Financial Modeling The statement may well be the deliverable of the project, but it conveys no information to the modeler. The goal needs more definition, such as “allow finance teams to price services” or even better “monitor 1,000 transactions through the portal per day.” See how such a defined goal portrays a stronger message. The reason why goals need to be stated and clearly defined is that they help to drive the design of the model and its outputs. They allow the modeler to understand the problems to be solved. They can then shape the specification the modeler creates. Goals are a key to the documentation.

Risk log It is important that everyone is aware of the risks inherent in a project. Something simple like “the client does not have the resources to test the model” should be included. The risk log should be created as a single document with the risk, the agreed actions, and the impact if a problem occurs. Everyone should be aware of this document, and it should be maintained constantly. One line per risk with all the details is the best way to maintain the log.

Issue log So, what is the difference between an issue and a risk? This is something every modeler should learn and keep in mind every time a model is being developed. The key difference is that a risk is always uncertain and could might or might not happen. An issue is something that has already happened and needs to be solved (if not, there may be a risk of something happening). An issue log should be maintained by the modeler alongside the risk log.

Model design The design for the modeling project is a core element in the financial modeling life cycle. This design phase is about planning and carefully scripting how the model will look, feel, and work: •• To design a model end to end, all aspects of the model are covered in this stage including •• Decision on the type of model suitable for client scope and requirements (model types) •• The modeling environment (the support available) •• The modeling methodology that will be used (using own standards of one of the prevailing standards like FAST, OPERIS, BMP, or FMP)

77

78

Chapter 4 | The Modeling Life Cycle Explained •• The best practice level that will be implemented •• The financial standards to adhere (i.e., International Financial Reporting Standards (IFRS), US GAAP, Sarbanes-Oxley) •• The modeling styles to be implemented •• The in-model documentation •• The allocation of time and resource to the model build Depending on the environment presented by the client and the model type chosen, the modeler might need to spend some of the time in design preparing external linking schedules such as •• An understanding of the risks and dynamics of the business •• Adequately reserve for guarantees or options in products and develop hedge strategies •• Key drivers behind the incentive of influencing regulatory capital levels •• Different reporting and profit measures such as riskbased capital requirements The design of a financial model is discussed in more detail in Chapter 5.

Model build The build phase is the most technical aspect of the entire financial modeling project. This stage is the actual physical creation of the model generally using Microsoft Excel application. The build is dominated by model scripting and model technical build practices and is the realization of the physical financial model. There is a strong reliance on the skill set and experience of the model as to the quality of the model build. The aim for every financial modeler in the build stage is to look for simplicity with all the scripting. Models designed by an experienced modeler will always show a high level of adherence to best practices and intuitive methods. Ironically, modelers with limited experiences tend to use the build stage as a way to showcase complex and badly thought-out scripting which reduces the case of a model review and audit. In Chapter 7, we take a closer look at how the model building would typically look like.

The Handbook of Financial Modeling

Model testing Financial model testing is unfortunately rarely performed outside of the investment banking. This is perhaps one of the most overlooked phases of the modeling life cycle, and yet if performed properly, testing gives a model the strongest indicator of the model quality and that it performs as originally specified. There are a number of types of testing that should be performed on the financial model, and not all of them are required for every model. The modeler should be able to advise any tester of the model as to which test would be suitable and which are not. Model stress testing All financial models bring an uncertain scenario, because there is no way to accurately produce the future with 100% accuracy all the time. Financial models are one method of getting the prediction, but because they rely on assumptions made by people, they are not infallible. The power of models is that they are dynamic because change is reflected in assumptions which allows for a simplified viewing of reality. For financial modeling the simplification of reality means it’s impossible for the modeler to account for every possible event in the model. For example, the activation and spread of the COVID-19 virus in 2019–2020 and subsequent events surrounding that spread are unlikely to have been predicted accurately in a financial model prior to 2019. This is not a failure by financial modelers, but just goes to show that there are just too many variables to capture in any model. With this understanding of simplicity of modeling to real life, we should now understand that financial models will have a risk factor built into them. To address this shortcoming, risk managers developed stress testing as a tool to evaluate the potential impact on portfolio values of unlikely, although plausible, events or movements in a set of financial variables. The techniques of stress testing are based on testing either sensitivities or scenarios within the financial model. Most financial models can benefit from the sensitivity tests because they assess the impact of large movements in variables on the outputs without specifying the reasons for such movements. Sensitivity testing An example of sensitive impact could be a 1% increase in annual inflation which brings a 2% decrease in annual EBITDA (earnings before interest, tax, depreciation, and amortization). If a financial model is built to best practices, tests like these can be run relatively quickly.

79

80

Chapter 4 | The Modeling Life Cycle Explained This sensitivity testing will highlight the inputs which have the greatest effect on results and identify them as key drivers. Sensitivity testing can also test if the model is realistic, because users will generally have some idea of what to expect when they make a change. Sensitivity tests are useful for exposing the accuracy of a model if accurate enough. If we know there is a linear relationship between input and variable, then we can gauge the expected change in the outputs. For instance, if we increase the cost of goods sold by 10%, our gross profit should decrease by the same level (10%). Sensitivity testing has its limitations. You have to be careful how much you change each assumption, and how you compare the sensitivity of one assumption against that of another. Because it focuses on changing one element at once, to see the effect, you can’t get a feeling for worst or best cases, nor for the probability of good or bad results. So, it should be used together with other tests, and not on its own. Scenario testing Scenario testing is somewhat more challenging because it relies on the financial modeler building a model with option trees. Scenario testing looks at the impact on a set of alternative scenarios such best case, worse case, base case, or (pessimistic, expected, and optimistic), once they are run through a model. Each scenario will consist of a set of assumptions and inputs chosen by the user. This approach is very useful for business planning and risk management, because it shows the impact of different conditions. Scenario testing is quick, and it is easy to present the results to management, to show them best- and worst-case extremes. On the other hand, it can’t tell you how likely it is that each scenario will occur or whether there are other important scenarios that need to be tested. We would need to combine the scenario with a probability assessment such as Monte Carlo to get a better picture of the likelihood that the scenario will play out. In Chapter 13, there is a more detailed discussion of stress testing and other types of testing.

Model review There is a likelihood you have had both the terms model audit and model reviews in reference to financial models and wondered what the difference is. To set you right, there is no difference; they mean the same thing. The difference comes down to liability implications and how the auditor qualifies a financial model. We will use the term model review going forward in the book to mean both audit and review. The model review process is painstaking and very exhaustive by nature. At some level every cell in a financial model must be examined, and the

The Handbook of Financial Modeling relationships to other cells and the impact of the final model must be exposed and documented. The time it takes to complete a full model review on financial model can be measured in hours, days, and weeks depending on the complexity and size of the model. Complex and large models will almost always take weeks to fully be reviewed. The Impact will be felt in the final bill. Model reviews are expensive firms that perform the review bill on the hours taken to review the model. The takeaway from this charging is if you want to reduce the model review, simplify the model, make it as light as possible, and build it to best practices. In Chapter 14, model reviews are covered in detail; however, we can summarize the review process as being based on a number of checks: •• Inputs checks ••

Data

••

Assumptions

••

User inputs

•• Calculation checks •• Running tests •• Reasonableness testing •• Low-level review •• High-level review ••

Sensitivities

•• Final report and review

Handover and maintenance The model handover is the phase where the modeler passes the responsibility of the model to the sponsor and ultimately the final user. This involves the activities that are performed prior to handover and after the handover preand posthandover, respectively. Prehandover preparations During the predelivery stage (running in parallel with model development), the modeler should consider how to prepare the maintainer to accept the model:

81

82

Chapter 4 | The Modeling Life Cycle Explained •• This may require holding some workshops for the sponsor and users to get acquainted with the model. Typically, the workshop will be including the following: •• A walk-through of the functional specification for the model •• A review and finalization of the user manual by the modeler with the maintainer •• A review of the technical manual by the modeler with the maintainer •• Providing the maintainer with the testing document and detailed brief on results and potential issues •• A review of the version control and version history detail with user details •• A review of the details of username, password, lockouts, and access controls •• Deployment diagram if applicable •• Model configuration and build •• Details of any support tools, databases, and applications that are required •• A thorough walk-through of the full capability of the model, including examining the structure and any VBA coding The model handover In the handover stage, the responsibilities of the model and accompanying materials are transferred from the modeler to the maintainer performing maintenance and support. Typically, these actions will be taken: •• Transfer of the model through an agreed method •• Transfer of data, assumptions, manuals, and other documents and materials reviewed in prehandover preparations and also that are required to operate and maintain the model •• Transfer of all previous builds and versions of the model. An acceptance from the maintainer confirming the items handed over, which should include versions and dates (It is sometimes preferable to also have an assurance from the maintainer that the items in prehandover have been covered.)

The Handbook of Financial Modeling Posthandover and maintenance The posthandover phase involves the modeler providing support and maintenance to the model and support for the maintainer for any activities that could not be provided for during stage 1. This phase would also involve a general maintenance of the model for a limited time only. This is potentially the most contentious aspect of the handover because it involves setting time limits on the length of time of the support. In addition, any possible handover activities that are required to be performed on the model should be clearly communicated and an assessment given of their impact on the model. Another aspect that would cause potential issues is the financial remuneration connected with the support. Does the modeler charge for this maintenance or is this part of the modeling brief and project? This situation should be based on a firm agreement between the receiving entity and the provider.

Conclusion Now that you have awareness of financial modeling life cycle, it should bring some structure into the process of delivering a financial model for a client, or for internal stakeholders. As I mentioned earlier, not all the phases will be required in every model, but I do stress that every modeler should be aware and comfortable in managing every aspect of the life cycle irrespective of whether they use each phase. Financial modeling is still seen as dark art pockets of industry; there is a mistrust as to the effectiveness of models and misunderstanding of what financial modelers practice on their trade. Using the life cycle as a guide will reduce so much of that mistrust, by bringing professionalism, ethics, and consistency to the financial modeling space.

83

CHAPTER

5 Planning and Designing Models Evidence from involvements of hundreds of financial modeling suggests the majority of models built have no planning involved. There are some cases where there really is no need. But as a financial modeler, at some point, you will need to have some coherent plan for your models, particularly when working on a project where the modeling is only one aspect, such as being on a bid or in a transformation program. It is critical to understand not just how to build models but also how to fulfill all the aspects of planning. This way, you will provide a final model that meets and exceeds user expectations. This chapter continues from Chapter 4 on modeling life cycle and will take you through how to plan a model and also how to design a model.

Planning to build a model The planning of the financial model helps to eliminate not only mitigates against surprises, but it defines what will be delivered. Think of it this way without a plan, what are you delivering? The start of planning is marked by a feasibility evaluation of the project, followed by scoping and then creating the modeling specifications. © Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6_5

86

Chapter 5 | Planning and Designing Models To give you just a flavor of the issue’s modelers is likely to face from the outset of a modeling project, I have described a few in the next few sections. These issues seem to crop up irrespective of where you build the model or what type of model it is, which should be highlighted in the feasibility evaluation.

Having an understanding of cash? At the outset the understanding of cash seems reasonable. However, a common mistake found in models is a lack of solid understanding of what cash is from the modeler. So, ask yourself these questions: ••

Are revenues cash?

••

Are gross margins cash?

•• Are profits cash? The answer to all three of these questions is a resounding “no.” If you didn’t know this, don’t panic. Not everyone in the business world is clear about this either. Then, what is cash? The key to understanding what cash in an organization is is to create cash flow statement; there is no other way around it. Every financial model that is looking at the effect of cash should have a cash flow statement. Without this statement, the user will have difficulty with even performing rudimentary tasks like balancing the balance sheet, estimating availability of funds, or even understanding when the bank account will be in deficit. Read through the following example: Suppose you sell something this month for $100, and the cost of making it was $50 in total. You have to pay your suppliers within 30 days, while the buyer probably won’t pay you for at least 60 days. In this case, your revenue for the month was $100, your profit for the month was $50, and your cash flow for the month was 0. Your cash flow for the transaction will be negative $50 next month when you pay your suppliers. Although this example may seem trivial, slight changes to the timing between cash receipt and disbursement, even just a couple of weeks, can bankrupt a business. Therefore, a good model will reflect not only cash flows generated by the organization but also their timing.

It’s all in the detail! Before building a model, take a look at the financial information that has been requested by the sponsor and model users to assess the level of detail required in the model.

The Handbook of Financial Modeling For instance, a sponsor might ask to have outputs which provide a summary of the profit and loss ever for the next financial year. Sounds simple enough but when planning the model outputs, it will soon become apparent that to derive the profit or loss, you need to know the revenue. But then you also need to know what is the gross profit and then the EBITDA and so forth. Also, the timing for the next financial year will mean you need to have the model planned into months or even weeks. My advice is to always plan to build at the detail level; the financials should be constructed from the bottom up and then validated from the top down. A bottom-up model starts with details, such as the types of revenues and when they are invoiced and received or the different types of expenses and again when to expect to pay them. The top-down validation means that you examine your overall summary and compare it with the bottom-up details to be sure they match.

Create scenario analysis and sensitivity analysis When planned adequately, a good financial model will include some scenario and sensitivity analyses showing how your projected results will change if the assumptions turn out to be incorrect. If planned properly, the building of these scenarios will subsequently help the user identify and track the assumptions that can have a material effect on future performance. These can then be validated further during the testing phase of the modeling life cycle. Performed after a scenario analysis, the sensitivity analysis is similar with one significant difference. Instead of changing all the variables simultaneously, you change one variable at a time to its own best- and worst-case value and rerun the model. Then, reset the assumptions to the base case and go on to the next individual variable and so on. The result from this series of iterations shows which of the assumptions drives the greatest variation in the results or outputs. These specific variables are the ones the user must control to optimize future results.

Assumptions: how realistic are they? During the planning, it’s important to set the tone of how the assumptions for the model are going to be validated. Validation of assumption in a financial model is a process where the modeler seeks proof or verification from the source of the assumption which is recorded.

87

88

Chapter 5 | Planning and Designing Models The validation is important from the modeler’s perspective, because once that is finalized, the modelers will input the assumptions into the model and will be responsible for how those assumptions are interpreted. The question of ownership of assumptions is critical. While the assumptions will be given to the modelers and therefore will have an owner and contact, once they enter the model, the modeler is responsible for having them in there. If you don’t understand an assumption that is sitting within your model, then it should not enter the model. Why? It is because you will have to validate every assumption in order for the users and owner of the model to have assurance that the model is fit for purpose. Ironically, validating the assumptions can be time-consuming and requires effort in people management. As a result, it is somewhat common to find good working models where the modeler has not fully validated the assumptions. As a result, the assumptions remain in the model, but there is no rational link with reality. I warn against this practice because it leads to the modeler’s integrity being questioned. The assumption validation is a two-way process. First, the modeler collects and organizes the assumptions and then sends them back to the original provider of the information. The provider should then confirm that the information now in the assumptions is valid and can be used in the model. By acquiring this information from the assumption owner, the modeler can subsequently make a more informed opinion on the assumption and start to validate. The validation should be based on getting a second or even a third opinion from different sources. If this is not possible, try to throw the assumptions back to the original owner after some elapsed time to see if the assumptions remain the same. Modelers need to have a firm grip on the assumptions and be willing to push the owner of the assumptions to move as close to reality as possible. For example, few companies achieve huge growth in revenues, profits, and cash flows after a slower period. Projecting numbers that an organization cannot support is never a good idea. It not only wastes your time but assists people in making ill-informed and hence bad decisions that will have long-term negative perceptions on your modeling ability. Something to keep in mind is that the majority of people who will be viewing and making decisions based on the outputs will be looking for some input from the modeler as to the profile of the assumptions. For example, they may ask if the assumptions are practical and, if so, how pragmatic, or are they based on empirical evidence and so forth. While it is valid practice to provide some feedback into the assumptions, stop short of making overall assessments, such as that the assumptions are “aggressive” or “conservative” or even “pessimistic” (even if you truly believe they are). Why is this restraint needed? By giving a general assessment such as “conservative,” you will be creating a message that somehow the assumptions have been massaged to suit the audience, which brings the credibility of the model and the modeler into question.

The Handbook of Financial Modeling Furthermore, with these types of assessments, modelers open up themselves to someone in the audience wanting to take a different angle. For example, if you decree that the assumptions are conservative, you may be directed to make them more pessimistic. This does happen, and more often than not, the modeler is left with trying to shape the results from the model to suit another’s views. The solution is to use the scenarios that have been built into the model and create a scenario that shows the pessimistic view without altering the base model assumptions.

Missing key elements in financial statements Make sure that all the financial statements and outputs conform to generally accepted accounting principles. For instance, if the organization’s financials are caught under IFRS (International Financial Reporting Standards) and the model is reporting revenues, then be sure that they conform with the IFRS on revenue recognition.

Build a realistic timeline Plan how far the model will project. Will it be three years, five years, or even ten years? Is it possible to project the years? If not, then how credible is the model? With most models, it is common to project out three to five years into the future. And while nobody can see five years into the future, having this projection in the model gives some assurance to the model users and anyone else reading the model that you have thought through the process and validated your initial assumptions.

Know the key metrics and indicators As much as possible, the financial model should provide baseline data for historical comparison and to assess the impact of change. In addition, you should be planning what type of metrics key performance indicators (KPIs) to include in the model. Much of the planning for metrics should come from the model sponsor who should advise you on the company reporting standards. However, as a modeler you also should be in a position to understand the meaning of various KPIs and bring suggestions to the sponsors to enhance the reporting.

Developing a feasibility assessment The modeler should commence a model project with a feasibility assessment of the entire model project or a preapproved feasibility. More directly, the modeler must assess the relative merits of building the model with reference to physical constraints, such as resourcing, monetary constraints, and skills availability. This assessment will encapsulate aspects like the following:

89

90

Chapter 5 | Planning and Designing Models ••

Determine the knowledge and size of the team (it could be just yourself) and the adequacy of the resources.

••

Establish the timescales from start to delivery and if they are realistic. You will need to cite examples of other similar projects.

••

Evaluate the risks and potential pitfalls of developing such a model.

••

Assess the relative importance of the model, such as whether it will be used to make key decisions. Is this a onetime-only model to help in a process? Or is this an ongoing model? You will also need to clarify the key personnel, such as the users, owners, stakeholder(s), sponsors, and those who have a vested interest in providing information for the model.

••

Consider the readiness of the project, organization and resources, equipment, and software. In other words, determine how rapidly all of these elements can be mobilized.

••

Review the appropriateness of the locations or which will be the ideal location. If there is a lot of in-person communications required, the project will benefit from being close to key personnel.

••

Know the cost impact of having or not having the model.

••

Establish if the deliverables are clearly understood. If not, they will need to be developed and stated manifestly at this stage.

••

Consider if this exercise is going to be a team effort. If so, the roles within the team should be very clear at this stage. In addition, the resources and time commitment that will be available during the course of the project should be planned.

Scoping the modeling project The scope is a very critical aspect of the planning. As a modeler, you should insist on having a clear and unambiguous full scope document signed off by the sponsor and approved by the users and stakeholders. I reiterate the word “full.” This means that all parties understand not just that which is in scope but also crucially what is out of scope. For instance, a scope may state that the model “will be used to support the finance teams to identify the key cost drivers.” This statement is short and vague, so it will be your responsibility to tie it down. For instance, in this situation, you could start by addressing these questions:

The Handbook of Financial Modeling ••

Who are the finance teams? They need to be stated by either the team name or the chief contact.

••

Are the finance teams responsible for providing the information and data to the model? If not, who will? Does the modeler need to build this information?

••

Can we define support? Is this a onetime model for a precise purpose and limited time, or is this an ongoing model that will need to be maintained and refreshed with data?

••

Do the cost drivers include resources (staff ) time?

Once you have covered just about every conceivable aspect, write a scope document, which will need to be approved by the model sponsor. I recommend that as the modeler, even though you may be given the scope, be proactive in the scope document creation. Take responsibility for writing the scope document in order to understand exactly what the full project entails. You will also be able to get some control over scope creep, which is very common during model builds. The scope document is the critical element that you would use to control scope creep with the model sponsor, the stakeholders, and the model users. Keep a copy of the approved document and circulate copies to the sponsor and stakeholders. Also place a summary of the scope in the model where it will be visible, such as a part of the documentation or in the assumptions.

The specification and strategy The specification should be a detailed document with a series of requirements for the model that have been gathered from the eventual model users, model owner, sponsor, and stakeholders. In this stage, the modeler should identify the output parameters (generally the financial statements) of the model. The modeler should also have a design for the types of calculations that will be used in the model and should assess whether there will be a need for VBA programming. The question of the VBA is important for the reason that not all modelers are competent at coding in VBA. What if VBA coding is required and the modeler does not have the skills to deliver such a model? The answer is to alert the project sponsors about the situation. At the same time, the sponsors should be advised either to bring in a VBA programmer to assist the modeler or to secure a modeler who has the VBA skills. It is also important to identify the inputs required for the financial model. Finally, the model parameter should be identified, and all options should be highlighted.

91

92

Chapter 5 | Planning and Designing Models The specification will be quite detailed and will be the reference template that the modeler will use during the design and build of a financial model. The specification is crucial to the model design and therefore should not be produced to reflect the modeler’s point of view. It should instead reflect to a large extent the specification of the stakeholders and the users. The sponsor of the model who may be a stakeholder should sign off on the specifications before you begin any design and build. This is a critical point because many model designs commence before the specification sign-off, for several reasons such as the sponsor is too busy but wants results immediately. My advice is: do not be compromised—this is your design plan and also your checklist when the model is complete. In many ways, this is your insurance against scope creep. If you were a constructor, would you start building someone’s dream house without the architect’s plans? Be strong; do it right! The specification should address the following requirements: ••

What is this model for?

••

Whom is this model for?

••

What should the model do?

••

What are the inputs required?

••

Where will the data and assumptions come from?

••

What business logic is required?

••

What level of detail is required for the model?

••

What flexibility is required? In other words, what needs to be able to change?

••

Who will use it and how? What are their skills?

••

How often will it be used, for how long, and how?

•• How soon is the model required to be live? These are the requirements that should be gathered in the early stages of the project. In fact, begin working through these as soon as the scope to the project has been produced. (Always entertain the idea that there is a scope document. This is not the modeler’s responsibility to create, but it will be the modeler’s responsibility to communicate.) You should be as detailed as possible and remember not to make any of your own assumptions as this impartiality will really help when you design and build. These requirements should always originate from the people who want the model. The modeler can fill in technical, economic, and resource implications as well as any constraints once base specifications have all been put together.

The Handbook of Financial Modeling In the beginning, clearly identify the stakeholders and the sponsor (usually the same person who has asked for the model) and their roles and responsibilities within the project. The sponsor should be able to provide a set of high-level requirements that you can use for the specification, which will be your initial template. The sponsor’s requirements are a key component. Therefore, should the sponsor fail to provide the document, insist that you are given access to someone who can give a clear view of the scope. Under no circumstances should you, the modeler, be pushed to a position of creating an initial specification. If you do, you will then run the risk of any project failure due to unclear specifications and miscommunications from feedback. This aspect will ultimately decide the success of the modeling project. For all modeling projects (irrespective of size), develop the habit of documenting the specifications and model design because it provides a visible and relatively easy checklist during the testing period. I liken this to a presentation. How can you be sure the presentation has gone to plan without an agenda to refer to? It is extremely important for the modeler to fully understand the business logic, such as all the business rules that need to go through the model. For instance, many business models involve some type of taxation or accounting for inflation (usually termed “indexation”) so that you would expect some rules on how the model will be affected by implementing such rules. Also be sure to heed the warnings surrounding errors in logic and especially omissions as they are among the hardest to find in any model. Don’t underestimate the damage that errors can do to the model and how quickly a modeler’s work can be undermined if errors are left unchecked. In the specification stage, keeping all source documents, files, notes, and discussions is imperative for reference, as these should guide the modeler as to the business logic and model. Keep in mind that ultimately the closing working model will reflect this understanding by the modeler and any weaknesses in the modeler will affect the concluding model. However, it seems obvious that the modeler should maintain a healthy respect for referencing information regularly throughout the project. For example, if you are modeling capital investments, you would need documentation on the actual item’s lists, depreciation schedules and valuations, assets conditions, and so forth. My advice is to keep all documents, review, read, understand, always question, and get confirmations. Never in any circumstance leave yourself in a position where you cannot explain the business or project due to a lack of understanding. If you do, you will eventually be found out. If this occurs very late in the project, the modeler would be expected to take full responsibility for any mistakes in the model that reflect this lack of business understanding. Suffice it to say, every modeler should be covered by professional indemnity insurance.

93

94

Chapter 5 | Planning and Designing Models

Defining model outputs The first stage during the model specification process is to refine the broad output requirements that were defined from the scope stage into defined outputs that the model will produce. Do not underestimate how much time and effort this step can take. On a large project plan, this can be a matter of days and possibly weeks to get a final specification. Note this difference: the scope is about “where do we want to be?” and the defined specifications are about “what do we need to get to where we want to be?” The simplest method of presenting the model outputs is to produce templates or outline reports using Excel. Outline reports will look like the final output without the data. These outline reports will give everyone involved the best possible idea of what the last outputs will look like early and can also be approved or modified by the model owner. Whenever possible, try to get the model sponsor to produce the outline reports, as this will add to the sign-off of the specification. This is a stage in which the model sponsor needs to be involved to agree on what information is required in the model reports. Here is a list of typical questions that need to be answered: ••

Who is going to use the model reports?

••

What purpose is each model report going to serve?

•• What is the appropriate level of detail to include on each report? When you have established an outline for the model reports, you can consider the calculations needed to give you the required outputs.

Defining calculations Developing the calculation rules that define the workings of a model can be difficult, especially when your understanding about the problem to be modeled is vague. That is why the process of defining the model specification will most likely be iterative, as more than one attempt is required before you get it right. In order to develop the calculations, you will need to address the type of information organization you will use. For instance, will the model consist of several tables with data? Will there be user inputs to affect these tables? By thinking through the data, it will become clear about the types of calculations and hence functions and formula that will be required. For instance, if there will be numerous tables holding data, it is certain that the lookup functions such as MATCH ( ) and INDEX ( ) will be required. Also, if totals are required from these tables, you will not be able to ignore the SUMIF ( ) or COUNTIF ( ) functions.

The Handbook of Financial Modeling When defining the calculations, start by listing the functions that will definitely be required. Then, list those that will be useful and finally those that will have very minimal usage. In this way, you will have a record later for documenting the calculations used in the model.

Defining the inputs Once you have defined the model calculations, the inputs required for the model should be implicit (based on intuition and specification but have not yet been formalized). It is frequently worth considering in more detail what inputs are required and how they are to be sourced. It is never easy defining inputs because by their nature, they rely upon the final user’s vision of which sensitivities they will need, which may not be available during the planning. My advice is to look at the outputs, which should have been defined previously. It should be clear from these outputs exactly what types of inputs and sensitivities will be required, although this is also a matter of what level of experience the modeler has of such projects. For instance, if the outputs (reports) have an income statement showing five years of revenues and financials, it is certain that inputs of the selling price for five years will be required. One method is to list the various inputs and types in a data sheet; you can then map these input items to actual outputs. A data input list of this form is useful for the following reasons: ••

Establishes the level of detail required in the input assumptions at an early stage in a form that is easy to communicate.

••

Highlights where special effort will be required in data collection and assigns responsibility for producing the data.

•• Lists the type of estimate that will be used for each input assumption in the status column. This can help identify the inputs that will be candidates for sensitivity analysis. Creating specification of a model can be challenging, which would explain why very few models have a specification. With small models, there is little need for these specifications; these types of models are generally not complex. For large models that will have a complexity, forgoing the specification increases the risk that the final model will not fulfill the needs of the model user and the model sponsor. The best way to view the specification is a blueprint for the model building.

95

96

Chapter 5 | Planning and Designing Models

Designing the financial model Going through a model design will ensure that the physical model will work once it is built and will actually function in the manner that is expected in the planning. How the model is designed will be influenced by the ability of the modeler to translate the requirements into a physical tool. This means prior to designing the model, the modeler must look at aspects such as ••

The impact of the requirements on the three key modeling concepts: inputs, calculations, and outputs.

••

The intended use of the model: This will determine if it will be a deterministic-type model (a deterministic model is one that, given a fixed set of inputs, always produces the outputs) or a stochastic model, which means the modeler must consider the effects of probabilities on the outputs.

••

The timescales of the model: Is this a time-value model or one that represents a specific moment only?

••

The dependency of the model on external data such as databases and ERP (enterprise resource management) systems.

••

The potential size of the model, which is usually based on how much data the model is expected to hold.

••

The project timescale, which will allow the modeler to assess whether building the model is realistic.

•• The complexity of the modeling project: The model will generally reflect the environment that it is built in; a complex environment is likely to require a complex model. Don’t be tempted to start building the model too soon, which typically happens when you are under pressure to produce results from the model quickly. If you are under pressure to deliver a model, check through the project plan to see you have provided adequate time for each task. It’s possible you may have underestimated the time it takes to complete the model, and therefore expectations of the model delivery by client are unrealistic. Underestimating the time it takes to deliver a model to the client does occur far too frequently and can have serious ramification for the client and for the modeler. My advice if confronted with such a prospect is to approach the client sponsor being clear about the issue. Run through the original plan with the sponsor and highlight the areas where the plan can be shortened with

The Handbook of Financial Modeling additional resources and ask for the sponsor to approve. Once approved, create a new plan with the additional resources. It is imperative that once the new plan has been approved, you can and do deliver on the model. Taking time to complete the design is well worth it, because it will allow the modeler to manage any complexities all during the design rather than when building. You will also enjoy the following results: ••

The model is quicker and easier to build because you have a model specification that describes what the model will do rather than having to work it out as you go along.

••

The model is less prone to errors if you have a written description of how the model works.

••

The model is less likely to have to be reworked if you have taken some time to build a common understanding of the requirement of the model. To have such an understanding will mean the design should be preceded by a project scope document that has been jointly agreed upon by the model sponsor and the modeler.

Managing complexity There are several books that cover writing error-free software, none better than Code Complete (second edition) by Steve McConnell (Microsoft Press, 2004). McConnell states that the most important problem is managing complexity, which is a problem with financial modeling simply because Excel’s versatility comes at price. Excel models tend to become complex quickly and easily. One of the reasons why so many Excel models become far too complex is that there are literally so many facets to Excel. With so many functions, codes, and utilities, there are just too many that are not matched by a user’s knowledge. If asked to rate their ability, many Excel users would claim to be far higher than an independent experienced Excel practitioner would. In other words, most believe that their skills in Excel are more than adequate, and why? One reason may be because Excel does not impose any intrinsic methodologies and structures on the user. For example, if you look at a complex model, you would only see one formula at a time, and it may refer to cells and sheets you cannot see. What you can see is (often) a sea of numbers, which creates visual clutter. What this means is that users are not always aware of what is really going on outside of the cell they are working in. And because there are a few alerts given by the application, users will actually believe that once a formula has been created, everything is okay. Herein lies the problem—this is not necessarily the case.

97

98

Chapter 5 | Planning and Designing Models As a result, it is possible to use some of the functions erroneously without really understanding their full impact until quite late in the modeling process when those errors start to appear. Most modelers at this stage would plough on regardless, firefighting any problems as they arise. Unfortunately, the result would be a finished model that is really a hodgepodge of functions, hardcoded adjustments, and dead links that has gone some way off the original route. Figure 5-1 presents a high-level design model of medium complexity in a flow diagram. You can clearly see that the model will be made up of several items or modules, such as the time-related inputs, the workings (calculations), and the reports. These modules have been classed into categories, for instance, inputs, calculations, or outputs. Notice the addition of the category called “Admin.” This topic will be covered later in Chapter 14 when I discuss modeling in a way that gives the users transparency.

Figure 5-1.  A high-level diagram of the model components is shown here

By creating such a diagram, you can start to see how these modules (which are essentially worksheets) will link to each other, and you can begin to make a map of the entire model. You can consider the data flow and links between the modules in the highlevel diagram by creating a data-flow table. The data-flow table is useful as a control mechanism for the data and links, and it also serves as a checklist of the data during the model building. A sample of a data-flow table can be seen in Figure 5-2.

The Handbook of Financial Modeling

Figure 5-2.  A table with the data flows in the impending model serves as useful control for the modeler

The next part to the design is to explore each of these modules and decide the layouts, the look and feel, and the information that they will hold. Start by developing a template that will be the standard template for all the modules in the model. Lock these standards into the Style feature in Excel which will make them available across every worksheet in the model. Figure 5-3 is a snapshot of the model-fixed inputs template. Notice that each individual section is clearly labeled; also, there is an unused column in column A. This column will be used to provide references to the assumptions.

Figure 5-3.  This is a sample of the model-fixed inputs template which contains the nonvariable inputs to the model

99

100

Chapter 5 | Planning and Designing Models During the design of all the worksheets, the physical file size of the full model is part of the consideration. Excel spreadsheets very quickly become bloated because every activity performed adds to the file size. In addition, make sure that the specifications clearly indicate who will be the model owner and describe what exactly the model will be and which application it will be built in. Even though it may be clear to the modeler that the application will be Excel, this should still be stated in the specification to establish a clear understanding between the model sponsor and the modeler. There should also be some mention of the acceptable speed of processing. In the design, the modeler must be careful to keep these specifications in sight. With numerous worksheets in a model, each with numerous calculations, more computer processing power is required. Remember that it is simply not good enough to deliver a model that is not up to specification to the model user. Even though the model may function, it may be so large and so processorintensive that it takes minutes rather than seconds to perform any calculations.

Building your model At this stage, you should be clear about the model’s design; have an understanding of the inputs, calculations, and the outputs; and have in hand an approved scope and specification of the model. Now, it is time to begin actually building the model. In this section, I will discuss the intricacies of the model build and how to best approach it.

Define the modeling tool(s) for the job When performing financial modeling using Excel, it is first important to establish whether Excel as your only tool of choice. In such situations where there is a heavy reliance on data, I have also Microsoft Access and Microsoft Power BI to manage the connections in a database system. However, for the purposes of this book, the tool of choice will only be Excel.

Have a clear approach There are two approaches to building models: the top-down method (see Figure 5-4) and the bottom-up method (see Figure 5-5). I endorse the topdown approach because the other method can cause even the most seasoned modeler to make errors.

The Handbook of Financial Modeling With the bottom-up method, the problem is that this approach is focused on collecting data and how that data can be manipulated with calculations. This is the main priority, and therefore this approach ignores the overall structure of the model. In other words, it works at the detail end of modeling first and puts the comprehensive presentation last. The problems start to appear once the modeler is in the development stage, because inevitably issues surrounding merging the data to the outputs begin to emerge that weren’t foreseen and planned. As a result, the modeler now has some major reworking to do. Due to this unstructured approach, the modeler is most likely going to create errors along the way because the modeling is based on “as you see it” type thinking. Telltale signs of models built in this manner can be observed in the way that parts in the model just don’t seem to relate together. For example, often it is unclear exactly what each part from the model is doing and even if some of the parts are really necessary. The model then becomes more a showcase of the individual modeler’s changeable thought processes in each stage of the model and so lacks any real coherence or consistency.

Figure 5-4.  The top-down approach starts with the outputs

101

102

Chapter 5 | Planning and Designing Models

Figure 5-5.  The bottom-up approach starts from the detailed inputs and calculations, but the outputs are not used as the target

Let’s contrast this approach with the top-down approach by going through this example: A model that will have a cash flow forecast for the next three years and should also have actual cash for the previous year. How would you go about building this model? First, take a look at what you need to produce, the cash flow statement. Even though it was not required, you will need to create a profit and loss statement in order to look at revenues and costs. It’s also clear that the model will need to accommodate some data inputs from users of the model, so they can punch in the previous year’s results. Again, even though it hasn’t been asked for, you will also need to build in some sensitivity, which means including a separate area for the user to flex the model inputs. This top-down approach means that you are looking at the wider model and beginning to think about how the components will fit together. You are also defining the boundaries and subsequently working at the bottom in contrast to having no boundaries and working at the top. My advice is to work from top to the bottom by starting the model build with the outputs. Think in terms of the reports the sponsor and model users require and then work back into the inputs. That way, you will fit the inputs and calculations to the outputs, in contrast to a bottom-up method, where the outputs will not be known until the end of the model build. In this case, you will end up with far too many inputs and calculations.

The Handbook of Financial Modeling

Get approval of the outputs The outputs that will be the reports and statements should always be the modeler’s primary goal because they are the reason for the model build. Within the specification, you should have established the exact outputs. In most instances, the sponsor will have a clear idea of what is needed, such as financial statements (profit and loss, balance sheets, or cash flow statements) or budgets. It could even be a mix of these outputs and also include a number of financial valuations and financial metrics. Crucially the modeler will need to make sure these outputs are not only clear but are approved and signed off by the sponsor. The best way to achieve this is to create physical samples of these outputs without any financial data that can be presented to the sponsor. Then, the sponsor can make any adjustments and amendments and give final approval of the samples. Once the outputs are locked down, the process of building the model becomes defined, and the final goals are clear and set. Often, organizations will have standard templates or may require that any outputs have a particular layout and feel to them, so the modeler should also make sure that the model outputs are in line with the model user’s requirements.

Timescales When building the model, it’s inevitable that you will need to establish some method of working with time periods, which can be years, quarters, months, weeks, and even days. The trick is how to get the model to relate to moving periods, for instance, a change from reporting in years to reporting in quarters and then annually after the first year. In addition, the model needs to also have the ability to handle variations in dates, such as project milestone dates, project start dates, or even changes in payment terms for different suppliers. Creating dynamic timelines often presents major problems for modelers and as a result leads to shortcuts being taken, which later will prove to be counterproductive. The key is to build the model with the smallest time periods that could be effectively used. Don’t get concerned if the specification asks for reports to be in years. The actuality is that to get to those years, you need to have the months, so build the model based on months. If you happen to ignore this facet, you will eventually end up regretting it. Here is an example. You have been asked by the sponsor to build a model that gives cash flow forecasts for three years. You happily build a model that is based on years ignoring the months. Further down the line, you discover that, in fact, the model users will require the ability to process sensitivity analysis that allows them to see what would happen if they change their creditor

103

104

Chapter 5 | Planning and Designing Models payment terms from 30 days, 45 days, 60 days, or 90 days. This small adjustment will have a big impact on your model, and you will be forced to rebuild it because the effect of these period changes will affect all the date-reliant calculations on the model. The solution to this time issue is to create a template in the model that has the smallest time periods (such as months) to the largest (such as years) and subsequently be synchronized as in Figure  5-6. This allows the modeler to refer to this template for any dates and time periods and then use lookups to see when that date occurs within the time periods. For instance, using our example about the cash flow and change in creditor payment date, we could still produce a yearly cash flow for the users. However, when they made their change request, we could use the timescale template in Figure 5-6 to state the number of days. This timescale would then work out when in the year 30 days, 45 days, or 60 days occur in the cash flow.

Figure 5-6.  The timescale template is used to control the model time values by calculating all the different time periods that could be used in the model

Developing styles and templates We use colors in a model to create a modeling style as a way of providing guidance to the model user. Think of the styles as the key on a map. The styles just like the key describe the particular elements within the model.

The Handbook of Financial Modeling zBy creating a model style using colors, you can distinguish between the types

of information and also alert the user to how the model is processing the information. For instance, you could use a pale yellow to alert the user that this is an input field and use a gray color to signify that a cell has a function or link. This way, the user will not be required to do anything but observe. Choose your own color styles but make them distinctive and keep them to a theme. For example, if you use a pale yellow to designate an input cell, you could also use a pale yellow with a green border to designate an input cell that has a drop-down list. This way, the users will know that inputs are always a pale yellow, but you still have the option of distinguishing between types of inputs.

Figure 5-7.  This is a sample of a style sheet

Figure 5-7 gives a sample of a style sheet. This should be provided within the model to act as a legend and to inform the user of the color conventions being used. Look closely at the top of the worksheet in Figure 5-7. Notice that this style sheet is also incorporating the template format that will be used throughout the model as in Figure 5-8.

105

106

Chapter 5 | Planning and Designing Models

Figure 5-8.  This shows the worksheet template format

Define the structure of the workbook Each workbook should have a broad set of rules that are consistent across all the worksheets in the model. The modeler should always establish these rules at the start of the model build and maintain them throughout the model. For instance, column A could be left blank on all worksheets. (I leave this blank as I can then use it for documentation and assumption references before closing the model.) The other most important feature is to keep all data within the same structure of columns. For example, if Year 1 starts in column D and Year 2 in column E, this should be replicated across the entire model in the inputs, calculations, and outputs. By using a consistent structure, there are definite benefits for reducing the risk of errors, such as pointing errors.

Working with the inputs The inputs should be kept distinct from any other model information. I choose to always keep the inputs on a different worksheet, and, if there are unlike data types for inputs, also separate these onto different worksheets. A sample inputs worksheet is presented in Figure 5-9. Notice that the format and style are consistent through each model and that the inputs are distinguished from the calculations by using colors.

The Handbook of Financial Modeling

Figure 5-9. With this input’s worksheet, notice that the format and styles are now consistent

Figure 5-10 is different because the data is time-based. Therefore, a separate worksheet has been used, but the style still remains the same.

Figure 5-10.  This figure shows a time-based inputs worksheet

107

108

Chapter 5 | Planning and Designing Models

Working with the calculations What do I mean by the term “calculations”? Well, in their simplest form, calculations are the formulas that are used on the inputs to create the outputs. They are also the methods that are used to bring functionality into the model and make up the process of translating information into something tangible for the model owner or sponsor. I want to get these points across because the calculations are often seen as just a set of formulas. From my experience, little attention is given to them from anyone but the modeler. The calculations performed on a financial model are without a doubt the most critical element to any model. It is here where the modeler’s interpretation and understanding about the process, or business, are clearly demonstrated. Frankly, anyone reviewing a model will gain some valuable insight into the inner workings of the model by taking a look at the calculations. The reason so many users of models are put off by the calculations is more due to the aesthetics of the calculations rather than the actual calculations themselves. There can be nothing more frustrating than having a jumble of formulas staring at you with numerous levels of links all throughout the model. Therefore, it is vitally important that calculations have these characteristics: ••

Structured with a consistent

••

Following best practice by not having a long or too complex formula

•• Maintains row consistency First, consistently try to put your calculations into one worksheet as much as possible. Even if it means that it will be a long worksheet with hundreds of rows, you can invariably create categories and keep a neat structure. There is a good reason behind having just one worksheet. Calculations that are developed on several worksheets will lead the modeler to creating a myriad of links from one worksheet to another, which will be terribly difficult to follow. It’s very easy to then lose control and introduce duplicated formula between inputs and outputs. Clearly, such duplication is unwanted in a financial model because it creates unpredictability in the output results. By employing just one calculation worksheet, any issues with links and errors will clearly be coming from just that one worksheet. The one thing you must never do in your calculations: never have hardcoded numbers in your calculations! If you are wondering why, the reasons are that hard-coding numbers into calculations creates static variables that do not dynamically change with the user assumptions and inputs. They lead to flawed outputs and results, but crucially, the model user will be under the assumption the model flow from inputs to outputs is dynamic when in fact it is not.

The Handbook of Financial Modeling From experience, I have found that the use of hard-coded numbers in the calculations is a sure measure of the distinction between a financial modeler and an Excel guru. It’s unlikely that a credible financial modeler would want to associate with hard-coding calculations. The way to work through hard coding of numbers when there seems a need to add a static number into the calculations is to create an input with the assumptions and clearly label it for all to see why it has arisen. Then, in the calculations, refer back to that input. This way should something change in the future, the model is dynamic because all changes come from the inputs. In Figure 5-11, although I have not used any type of expansive functions, the calculations are in one worksheet shown in their categories. You can clearly see the link to the input and the subsequent calculation. The modeler should be aiming to maintain a structure that follows the inputs so that it’s easy to keep up with where the link comes from and how the calculation has been put together. It is also good practice to bring the actual input into the calculation worksheet as a link and then make the calculation from that worksheet and not directly from the inputs.

Figure 5-11.  The calculations worksheet follows the same logic as the inputs worksheet

109

110

Chapter 5 | Planning and Designing Models In Figure 5-12, the calculations are made directly from the inputs (sometimes referred to as a three-dimensional formula). Although this is still a viable way to model, it is clearly a lot more difficult to trace the calculations. Imagine that there are hundreds of inputs and calculations and there are some errors that need to be corrected. The method of finding them will now require switching between the inputs and the calculations: a switch that could be compounded if there are also numerous calculation worksheets. Although it seems like duplication bringing the inputs into the calculation worksheet and making the calculations in that worksheet, it is cleaner and more sensible modeling. Once you develop this method of working, it will become second nature.

Figure 5-12.  There are no links to the inputs; the calculations are made on the inputs directly

Working with the outputs The outputs will be governed by the approval from the sponsor and model users; therefore, it is likely they will need to conform to a specific layout and format. Even with this in mind, there should still be consistency. For instance, no matter what type of outputs (reports) are required, these should link to the calculation’s worksheet. In other words, do not make the mistake of linking the outputs to inputs. We have established the model process should always be

The Handbook of Financial Modeling Inputs link to Calculations link to Outputs The advantage of linking in such a manner is that the results in the outputs can be traced back to one or more inputs. This allows the model user to understand which assumptions are the key drivers to the model and hence the business. If we break the linking process and cause jumping from input to outputs, there are a number of issues that will arise including Transparency: The model user will lose transparency of the outputs because there will be a lack of consistency. Conversion: Any assumptions (inputs) that need some conversion such as currency conversion, which would be performed in the calculations, will be circumvented. That can only mean outputs will now be flawed as in Figure 5-13. Split variables: There would a likelihood of having outputs split between several unrelated variables. For instance, the gross profit in the income statement is based on the revenue less cost of sales. However, if in the outputs the cost sales is coming directly (even though there is one in the calculation) from inputs and revenue is coming from calculations, the model will start to have two sources for the same information. This is dangerous for modeling. Complex error checks: There will be complexity in creating meaningful error checks, as each check would need to come from more than one source. A model that does not uphold the linking process is usually a symptom of bad or lack of planning. By linking to the calculation worksheet, the flow of information will run from the inputs to the calculation to the outputs; therefore, any problems in the outputs can be traced to the calculations and then to the inputs and corrected.

Figure 5-13.  The staff costs in the outputs do not match the staff costs in the calculations worksheet because they have come from the inputs worksheet

111

112

Chapter 5 | Planning and Designing Models

Recap The model build will consist of a number of principles and actions. Here is what has been discussed so far in this chapter: ••

Think about which tools you will be using or require for the project.

••

Set yourself up for a top-down approach as opposed to a bottom-up approach.

••

Make sure the outputs have been approved by the sponsor and model user and then close off.

••

Develop a timescale template with the lowest time periods to the highest.

••

Develop a consistent worksheet template for the entire model.

••

Create a modeling style and format and put these into a legend template.

••

Work according to a defined structure for all the workbooks.

••

Create the inputs in one workbook but make a separate workbook for calculations and outputs.

••

Use the calculations and bring all inputs into the calculations. Do not use hard-coded numbers or fudge factors in the calculations.

••

Worksheets should have a flowing link. Calculations are linked to inputs and outputs are linked to calculations. Avoid hopping from outputs to inputs.

Planning for errors We have mentioned the errors in financial modeling in earlier chapters, but now we need to get a more detailed understanding of error. So, what are errors from a financial modeling standpoint? Errors are when an algorithm (usually a calculation performed in a formula) within the model has an expected result, which does not occur. The problem is not the error itself; the fact is often there can be so many different outcomes from any calculation single calculation that it would be impossible to predict all these outcomes. The issues in errors are the following: how does the model treat the situation where a predicted outcome does not materialize and is there a means where such an outcome can form an alert?

The Handbook of Financial Modeling The truth of the matter is when building a model, there will be errors, lot of them occurring. The goal for modeler is to understand where and why those occur and plan for them. The difficulty is not in the error you know, it’s the ones you don’t know, and again it’s all a matter of planning. Planning for errors means dealing with them, and this is more about the modeler’s mindset. The modeler needs to think about “what is it that made this error?” and then think further about what can actually happen. In other words, the modeler needs to be a couple of steps ahead of the model user in order to foresee the potential errors that can occur. For instance, an error may occur within a cell that has totals in it because the users may choose to overwrite the formula and put in place a different function that they feel is more suitable. Whether the model user has the right to do this is beside the point; the simple fact is that an error occurs because a calculation cell has been tampered with. The crucial aspect here is this: has the modeler foreseen this possibility and added some sort of error checking?

Creating the error template There are very instances where a financial model does not require error checking. As such, every modeler should understand the error checking mechanism. This will start with the modeler creating an error check worksheet that collects all the errors in the models on a worksheet-by-worksheet basis. What this means is that each worksheet can contain its own error checks, which are subsequently collected as a group check on the error check worksheet. After that, the group check is collected by the error checking worksheet as in Figure 5-14.

113

114

Chapter 5 | Planning and Designing Models

Figure 5-14.  An error check worksheet is shown here

In Figure 5-14, the error check is shown, and it shows the group check from seven worksheets (User Inputs to Financials). The error check worksheet then shows the status of all seven worksheets. Notice that the Time inputs worksheet has returned reading of FALSE. In this instance, the user is alerted of a critical error in the time worksheet, and all other worksheets are stable. The modeler should then produce error checks in each worksheet that catch specific outcomes for that worksheet and record the overall worksheet check at the top as in Figure 5-15.

The Handbook of Financial Modeling

Figure 5-15.  The time inputs worksheet with data is shown here. Notice that there is an error because something is missing

In Figure  5-15, the time inputs worksheet has an error in row 20, column U. The error stems from some missing information in column C. One of the modelers has anticipated that if any of the detail columns are blank, then an error will occur because the information is mandatory. The worksheet collects a total of all error rates at the top in row 1, column E, which is then sent to the error check worksheet.

Displaying the errors Although there is no standard method of displaying errors, I suggest you use visuals as well as providing a message—either “False,” “Warning,” or “True.” The message “False” means that a significant issue is apparent and needs to be rectified as it has an effect on the model. The “Warning” message is little used, but I use it to signal that there is an issue although it will not have any detrimental effect on the model. For example, “Warning” would appear where the user has input a number that is exactly the same as another number that has already been inputted. This would just be a warning to check that this is intentional. “True” signifies there are no issues and therefore no error has occurred. However, do not feel that you should use the same messages as I use, for instance, you could use “OK,” “Investigate,” and “Error” instead. Creating and formatting the error message is a two-stage process. First, select a cell, and on the Home tab and in the Number group, click the Dialog Box Launcher. Use the Custom Number format, and in the Type text box, type “FALSE”; “WARNING”; “ERROR”; or any combination that you wish to use (see Figure 5-16).

115

116

Chapter 5 | Planning and Designing Models

Figure 5-16.  The error checks can be created through the Format menu

Next, apply conditional formatting for each of the three conditions to the same cell, starting with Error. On the Home tab, in the Styles group, click Conditional Formatting and then click New Rule. Choose Format only cells that contain, as shown in Figure 5-17.

Figure 5-17.  The conditional formatting with a new rule is shown here

The Handbook of Financial Modeling There are three conditions that must be set. First, ensure that Cell Value is displayed in the first drop-down under Edit the Rule Description. Click the next drop-down arrow and select greater than. Click the last box on the right and enter the number 1. Now, format the condition with a red fill. Click the Format button, then the Fill tab, then the Color arrow, and then click Red (see Figure 5-18).

Figure 5-18.  Use the fill color to set the condition

Make sure you also set the font and font style (on the Font tab) to the preference that you require. Click OK when you are finished. Now, apply two more conditions: one for WARNING and one for TRUE. For WARNING, use the less than 0 condition with a fill color of orange (see Figure 5-19). For the last condition, TRUE, set the rule description to equal to 0 and use the green fill color.

117

118

Chapter 5 | Planning and Designing Models

Figure 5-19.  Establishing the conditional formatting for all three error conditions is shown here

Now, there are only two steps left for the modeler: determine which parts to the model require error checks and what exactly the checks should be testing.

Example of planning a financial model We will be planning an actual model from the feasibility to scoping and then getting the specification, putting together the model design, and finally creating a testing specification. We are not going to go through the model build, so the assumption will be that the model is built. This case study is focused on how to mount a feasibility study for a model build. The reason I have used this example is that the feasibility is the start of any modeling. It is a crucial piece for financial modeling because it will dictate whether the model build will continue or not. It is imperative that you understand the basics of building a good feasibility study to present to the sponsor or customer.

The brief The newly appointed vice president of financial analysis and metrics for Nonesuch Corporation is dissatisfied with the level of financial information available to the organization. The organization is going through a two-year transformation program to change the way it delivers services to clients, and the availability of up-to-the-minute and accurate financial information is critical to the VP’s decision-making.

The Handbook of Financial Modeling The VP has brought in a financial modeling firm to produce a feasibility study for the company on the strength of their financial information and provide any options on how to improve on the weaknesses.

About the feasibility study A feasibility study is a document that identifies each of the solution options available and rates the likelihood of each option achieving the desired result. It should include the following parts: ••

A description of the business problem (the modeling project)

••

A list of the requirements for a solution to fix the problem (or realize the opportunity)

••

Available options for delivering a solution

••

An assessment of the feasibility of each option

••

A list of the risks and/or issues associated with each option

•• A preferred option to be approved for implementation This feasibility assessment will be undertaken by the financial modeler and presented to the model sponsor. For our case study, the assumption is that the business case for the project will have been completed previously, and therefore completion of this feasibility will add more rigor to the solution options presented in the business case. The main purpose of the feasibility study is to ascertain the likelihood of each solution option identified for meeting the stated business requirements. Although the risks, issues, and constraints are important, the project is less likely to be a success if the solution option chosen is unlikely to be feasibly implemented. To determine the likely feasibility of an option, a range of “assessment” methods are undertaken. As there are a myriad of potential methods attainable to assess feasibility, I suggest you take time to consider the most appropriate method available in your project. The outcome of the feasibility study is the confirmed solution option for inclusion within the business case. The next stage, after the solution option has been approved, is to define the project scope and structure within the project’s terms of reference document (a statement of the objectives and purpose of the project).

119

120

Chapter 5 | Planning and Designing Models

The assessment As we work through this case study, let’s call this project the financial tool feasibility (FTF). Now, let’s break down the feasibility study into its components to be presented to the VP of financial analysis and metrics.

Problem statement When conducting a feasibility assessment or study, it is very likely that some issues will arise during the assessment. These issues should be collected during the study and then listed in priority from the most to the least severe.

Business environment Any successful organization requires timely and up-to-the-minute financial information to support decision-making and to forecast the future. Nonesuch Corporation either has lost or has not had the mechanism in place to deliver financial information that can be quickly and easily outputted to senior staff. Due to the demand of the transformation program, there is now a serious requirement that this financial information be available to the VP of financial analysis and metrics.

Business vision The corporation is looking to redefine how it interacts with its customers and clients in the next two years as a step toward achieving higher growth and profit maximization for the future.

Business units The current business unit relevant for this project is the financial analysis and metrics departments, which are parts of the wider finance department.

Business location This is a global business with locations across several countries and regions. This feasibility study is for the group vice president and is therefore relevant for every location.

Business information There is a need to understand the repositories, databases, and enterprise resource systems (ERPs) available in the organization, which once the due diligence has commenced will result in a data flow diagram.

The Handbook of Financial Modeling

Business technologies The list of the existing business technologies that are relevant for this project (like network-attached storage or data servers) is not available until the completion of the due diligence. Once the details are provided, a description for each major technology together with a technology architecture diagram to highlight the interfaces between current business technologies will be placed in this section.

Business problem The business problem is a lack of visibility of the key financials of the business and therefore no transparency. The reasons why this problem exists are currently unknown but could be due to the lack of historical investment in the financial systems and infrastructure. This problem is having a major negative impact on the organization’s response to its market. It is envisaged that the problem will need to be resolved quite rapidly as the transformation of the entire organization (not just the finance department) will be two years from start to delivery. This problem is likely to have an impact on the following areas: ••

The finance business process including efficiency, timeliness, clarity, accuracy, and relevancy

••

The financial analysis and metrics business unit

••

••

Definition (lack of financial vision, scope, and objectives)

••

Direction (misalignment with corporate vision)

••

Financial structure of the organization (currently no feasible method to measure the inefficient or inappropriateness of the current structure)

••

Financial performance (the product and service quality cannot be immediately measured in financial terms)

••

Financial data (validity and quality)

Business location ••

Security of financial data (exposure and risks)

••

Relevancy of the current financial information

••

Finances (too expensive and these finances may not be able to be measured)

121

122

Chapter 5 | Planning and Designing Models

Business opportunity The following opportunities have been identified in this project: ••

The availability and timeliness of key financial information

••

The possibility that the business unit can respond rapidly to the changing environment by having up-to-the-minute information

••

The ability to measure the cost and relevancy of the finance department and make further efficiencies

••

The ability to support the transformation by adding financial information to operations

Requirements statement The requirements statement is a document that contains information about the needs and goals of an organization or project. This statement can be quite detailed, but often it is written at a summary level so as to be communicable to a broad range of people.

Business drivers The key business drivers for this project are as follows: ••

An organizational transformation that must be achieved within two years

••

A limited timeframe for competitive advantage

••

Timing of other related changes to the business or external marketplace

Business requirements For each business problem (or opportunity) identified previously, document the detailed business requirements using the format shown in Figure 5-20.

The Handbook of Financial Modeling

Figure 5-20.  A list of opportunities and problems is shown here

Feasibility assessment A number of assumptions need to be made as we cannot adequately take on a full feasibility assessment in this case study. So, we should assume that we have now assessed and identified each of the solution’s options available and the feasibility (or likelihood) of each option meeting the requirements defined in Figure 5-20. In addition, we should assume that we have reviewed risks, issues, and assumptions associated with the feasibility of each option. The process for assessing the feasibility of an individual solution is shown in Figure 5-21.

123

124

Chapter 5 | Planning and Designing Models

Figure 5-21.  This figure shows the feasibility assessment process

Option one: Implementing off-the-shelf software This section gives a summary of the description of the option, the assessment, and the result.

Description The option is to purchase a renowned software package such as one of the following: ••

Quantrix Modeler

••

IBM Cognos

••

Oracle Hyperion

•• Statistical Analysis Suite (SAS)

The Handbook of Financial Modeling All the software mentioned will integrate with relational databases and provide a front-end interface that can be tailored to produce custom metrics and financial analysis.

Assessment Here are the methods that have been used to assess the feasibility of this solution: ••

Prototyping: This involved the construction of a demo software (called a prototype) to prove that at least a part of the full solution is achievable. In our example, the prototype was tested so that we could prove that the highest-risk areas of the solution are feasible and to test that the package can be integrated into other application systems used for the business.

••

Staff survey: This survey involved presenting the finance staff with a series of questions that had optional answers to assess their readiness and also their acceptance toward learning and using a new system.

Results The expected result from the assessment for this solution is that there would not be any significant issues in the implementation. The actual results that were born from the prototyping support that assumption. However, from the results from the staff survey, there would be a considerable cultural shift that would be required in order to use the software effectively.

Risks There are some risks associated in the software implementation solution. These risks are defined as any event that may adversely affect the ability of the solution to produce the required deliverables. Risks may be strategic, environmental, financial, operational, technical, industrial, competitive, or customer related. A list of the likely risks for our example is shown in Figure 5-22.

125

126

Chapter 5 | Planning and Designing Models

Figure 5-22.  A list of likely risks is shown here

When identifying the risks, I recommend that a formal risk assessment be undertaken and documented in a risk management plan to improve the likelihood and impact of each risk eventuating. Furthermore, a clear risk management process (including risk forms and registers) should be used from the outset.

Issues A list of current issues that adversely affect the ability of the solution to produce the required deliverables is included in Figure 5-23.

Figure 5-23.  A list of issues is shown here

Assumptions This is a list of the assumptions associated with the adoption of this solution: ••

There will be no legislative, business strategy, or policy changes during this project.

The Handbook of Financial Modeling ••

Additional human resources will be available from the business to support the project.

••

The organization as a whole will support the project.

Option two: Developing a financial model tool This section gives a summary of the description of the option, the assessment, and the result.

Description This option is to develop a dedicated financial model tool from a recognized financial modeling firm. The model will be expected to integrate with existing relational databases and provide a front end that encapsulates all the outputs based upon the user requirements.

Assessmentx Here are the methods that have been used to assess the feasibility of this solution: ••

Prototyping: This involved the construction of a prototype financial model to test the validity of implementing the current databases and also running with the incumbent ERP system. In our example, the prototype was tested so that we could prove that the highest-risk areas of the solution are feasible and to test that the package can be integrated into other application systems used for the business.

••

Staff survey: The survey involved presenting the finance staff with a series of question that had optional answers to assess their readiness and also their acceptance toward learning and using a new system.

Results The expected result for this solution would be that there would not be any issues to implementing a financial modeling tool. The actual results born from the prototyping support this assumption. The staff survey showed that while there would need to be a cultural shift, the negative effects of this shift could be minimized by making sure the staff members were involved throughout the development of the financial model tool.

127

128

Chapter 5 | Planning and Designing Models

Risks There are some risks associated with the financial modeling tool solution. These risks are defined as any event that may adversely affect the ability of the solution to produce the required deliverables. Risks may be strategic, environmental, financial, operational, technical, industrial, competitive, or customer related. A list of the likely risks for our example is shown in Figure 5-24.

Figure 5-24.  This is a list of risks for option two

When identifying the risks, I recommend that a formal risk assessment be undertaken and documented in a risk management plan to improve the likelihood and impact of each risk eventuating. Furthermore, a clear risk management process (including risk forms and registers) should be used from the outset.

Issues A list of current issues that adversely affect the ability of the solution to produce the required deliverables is included in Figure 5-25.

Figure 5-25.  A list of issues for option two is shown here

The Handbook of Financial Modeling

Assumptions This is a list of the assumptions associated with the adoption of this solution: ••

There will be no legislative, business strategy, or policy changes during this project.

••

Additional human resources will be available from the business to support the project.

••

The organization as a whole will support the project.

Feasibility ranking The ranking is a part of the feasibility assessment that compares the options and then creates criteria and scores these against each option.

Ranking criteria The ranking criteria are provided in Figure 5-26.

Ranking scores Score each option using the format shown in Figure 5-26.

Figure 5-26.  The criteria and ranking scores for both options are shown here

■■ Note  The score is typically a number from 1 (low feasibility) to 10 (high feasibility), and the weight is a number from 0.5 (criterion is unimportant) to 1.5 (criterion is very important). The total is calculated as score x weight.

129

130

Chapter 5 | Planning and Designing Models

Feasibility result Option two has achieved a higher total score and would therefore be the most feasible option for the solution. The key reason is down to its flexibility during the development. Therefore, the project can adapt to changes in the overall transformation program. Staff adaption would also be relatively easy because the staff would be actively involved in the development and implementation on an ongoing basis.

Conclusion This chapter has covered several aspects of the model planning, and I would not expect anyone to understand all that has been mentioned in one reading. However, this chapter is one that must be understood because it’s at the heart of the model design. Many of these concepts will also be featured again later in this book. If you have found any of the concepts unclear, I would advise that you read through this chapter again, focusing on a section at a time, and only move on once you have a clear understanding of that section.

CHAPTER

6 It’s All About the Outputs This chapter specifically looks at the model outputs as part of the design and building of a model. So far, we have looked more at the overall planning and design of models. This will be the first chapter that examines a specific feature of a financial model. All financial models should have outputs. So, let’s establish what is meant by this term outputs? The outputs are any reports, schedules, dashboards, and summaries that display the results of relationships between variables from the assumptions and inputs. I want to be clear that outputs are not calculations nor are they inputs. It is very common to have models where it’s hard to discern which are the outputs and which are the calculations. In a well-built financial model, the outputs are very clear and so are the calculations for that matter. Now that we understand what are and are not outputs, we can look further into how they are created and then look at some examples of outputs from models.

Deriving the outputs So, you have been engaged to deliver a financial model for a client. To complete the requirements, you need approval from the sponsor and the eventual user before you can start of the model design and plan. It turns out you have an issue; the sponsor won’t approve the requirements until they are able to know what the model is going to give them (the client). © Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6_6

132

Chapter 6 | It’s All About the Outputs It now seems you are caught in a cause and effect loop. The client wants a financial model but wants you to tell them what the model will do and give them. In the meantime, you need the client to tell you what the model should outputs. I have to say, this situation is very common. This will almost certainly arise because there is no feasibility study in place, so the sponsor would know there is an issue that needs to resolve with some sort of model and they won’t know how to recognize the solution when it arises. A critical goal for the modeler during the requirements phase should to have a defined output or set of outputs. If you fail to get these outputs defined before the end of the requirements, then the modeling project is almost certainly going to fail. It will fail because the sponsor is not clear about the solution and therefore the outputs are needed for that solution. If the modeler begins to build the model under such a cloud, then be sure the sponsor will continue to change their mind about the outputs throughout the project. In the end, no matter what you deliver to the sponsor it will be wrong. So how do we derive the outputs? Well it’s simple; as a modeler you must emphasize to the sponsor that they need to provide a sample, prototype of detailed specifications of the output they need. You see the outputs must come from the client not from the modeler, and once you have them, they must be included in the requirements and then replayed to the sponsor for approval. The outputs are your blueprint for the way you will build the model. Without them your model should not be built. I have been involved in financial modeling projects which have stalled at the requirements because there are no outputs approved by the sponsor. Conversely, I have also been involved in a modeling project that have no defined outputs, and all I can say is that it is something I will never do again.

A sample output We have established the need to start any model building with the outputs. Assuming the requirements have been approved and the modeler has been provided with the specifications for the one or more outputs, we can now look at steps required to bring these outputs to life. In Figure 6-1, we have an output template which has been prescribed through the requirements and approved by the model sponsor. The output is a consolidated cost analysis for IT services pricing. It gives us the eventual cost a company will need to absorb in order to provide IT services to its clients. This would allow the company to consider how to present a price to its client to provide the service that can not only cover its cost but can also make some profit.

The Handbook of Financial Modeling

Figure 6-1. The cost analysis outputs have been provided through the requirements gathering

The template in Figure 6-1 is currently having no data, but the modeler can now use the cost drivers (shown in column B) to derive the assumptions and inputs that will need to capture from stakeholders in the company. For example, we can see that the cost is split into sections, project and ongoing. Within each section we have a more detailed cost.

Step 1: build the inputs The modeler should take outputs and create assumptions and inputs worksheets that can record all the variables associated with each of the cost drivers which are listed in Figure 6-2.

133

134

Chapter 6 | It’s All About the Outputs

Figure 6-2.  A list of all the cost drivers

When creating the input template, the modeler should take into consideration that there are likely one or more variables associated with each cost driver. The only way to understand these variables is for the Modeler to investigate and analyze the operations of the company. The investigation is really an exercise in due diligence by the modeler who should conduct interviews and workshops with people in the company to gain as much information as possible about how the company operates and also about its cost driver. Figure 6-3 is the input template that has been derived from the due diligence.

The Handbook of Financial Modeling

Figure 6-3.  The input template is created from the cost drivers in the outputs following a due diligence of the business operations

From the due diligence, the modeler has found that several of the cost drivers are made up of more than one variable. For instance, the Transition Service and Account Management Cost are actually made up of a combination of hours worked x rate per hour. The modeler should then present all the variables in the inputs in order to give the model user the options to flex either hours or rate or both. The ability of the modeler to discern all the variables is critical to financial models because it creates a platform to create scenarios. There can be a few things more frustrating in building financial models than completing a financial model and later finding you have failed to capture all the required variables. Such a situation is a structure problem and will often require a rebuild of the entire model. Something to keep in mind is that you will notice that in Figure  6-1, the outputs are only looking at years (Year 1, Year 2, Year 3); however, the inputs in Figure  6-3 are structured in months. When you find that outputs are represented in consolidated timeline such as years, don’t be fooled into working in years, because invariably all the cost drivers and their associated variables will actually need to be calculated in months. For example, while we could show an output with wages and salaries in years, most people are paid in either days, weeks, or months. No one is ever paid in years. If you created an input template that worked in years, you would soon find yourself having difficulty accounting for pay rate changes during the year.

135

136

Chapter 6 | It’s All About the Outputs

Step 2: take the inputs into the workings Having created an input template, the modeler needs to think about how to bridge between inputs and outputs. We know there are a number of cost drivers that have more than one variable. You may be tempted at this stage to just calculate the variable, that is, hour x rate directly in the outputs. Doing such goes against financial modeling best practices, and never be tempted. The outputs should have no calculations. What is required is another worksheet to manage all the calculations. You can call this calculation worksheet anything you like, although I have used Workings. The important thing is just be sure the calculations are separate from the Inputs and Outputs as in Figure 6-4.

Figure 6-4.  The calculations are held in a separate worksheet called Workings

The calculation sheet serves three purposes: ·· The workings link to the inputs worksheet directly and bring all the input variables in a logical fashion. ·· The workings have formula that plays each of the variables against each other based on the business rules of the company. ·· The workings consolidate all the calculations ready to present them to the output template.

The Handbook of Financial Modeling The preceding three points are intrinsic to the workings and should not be missed out. Often, the financial model is missing one or more of the steps, which not only creates difficult-to-follow workings but also increases the likelihood of duplication of variables. The best practices on calculations show that if you bring the variables from the inputs into the workings, you can then refer to them within the worksheet from then on making it easier to follow a logical method. If instead you calculate directly from the inputs, anyone looking to review the model will have a tough time switching back and forth between inputs and workings. Further there is a high chance at some point the wrong variables will be matched together in workings. The last part is to make sure after all the variables are calculated they are consolidated. The consolidation is really a copy of the output. It serves to tidy up the calculations and gives a focal reference point for the outputs as in Figure 6-5.

Figure 6-5.  The consolidation of all the calculations looks just like the output in Figure 6-1

There is something you have possibly already noticed. In both inputs worksheet in Figure 6-3 and the workings, we have a series of numbers to the left of the cost drivers and variables such as Inp001 or Wrg001. These are in fact references to the inputs and calculations. Each variable in the input worksheet is given a unique reference ID, and every time we link to the variable from the workings, we then quote the reference ID. This allows anyone reviewing the model to very quickly understand where each calculation is coming from and which variables are driving it.

137

138

Chapter 6 | It’s All About the Outputs Additionally, in the workings every time we combine two or more variables in a calculation, we give the combination a unique reference. Again, it serves to make the review of the model easier. There will be times when you build a financial model that has so many variables with thousands of calculations. You need some way of being able to quickly pinpoint the relationships between each calculation and variables relatively quickly, and using references is the way to accomplish that. Also spare a thought for any reviewer or future modeler who has to update the model you built.

Step 3: link the workings to the outputs The final step is the most pleasurable, because it’s where you see the fruits of all the calculations and inputs come together in the outputs. The outputs should (as in Figure 6-6) now be very much a presentational worksheet. You can format it accordingly to how the sponsor wants, because you have already created the pro forma outputs in the consolidated calculations.

Figure 6-6.  The outputs which are linked to the consolidated workings

The Handbook of Financial Modeling There is just one more additional item you may find you need to add to your output. With some outputs especially when dealing with cost-related drivers projected over several years, the sponsor may require the ability to see the effects of inflation (indexation). There are several ways to accomplish this; however, the premise is always the same. If you need to present more than one of the same outputs with the effects of inflation (termed real and nominal in accounting speak), make sure you also make an identical consolidation in your working. For instance, in Figure 6-5, we have a consolidation of the calculations working. Now in Figure 6-7, there is an identical consolidation, but this one has an additional calculation to capture inflation.

Figure 6-7.  The output with inflation added

So, we have two copies of the consolidated calculations sitting in the working, separated by an addition of inflation. You may have guessed already; the inflation will actually be variable in the inputs which the user can manipulate as in Figure 6-8.

Figure 6-8.  The annual inflation can be adjusted in the inputs

Depending on the wishes of the sponsor, the two consolidated calculations can be shown in the outputs as two separate schedules, or you can have just the one schedule and use a toggle switch to turn inflation On or OFF as in Figure 6-9 (notice in Figure 6-6 the toggle at the top is OFF).

139

140

Chapter 6 | It’s All About the Outputs

Figure 6-9.  The inflation toggle has been turned ON

Conclusion The chapter has taken you through the structural aspect of building the outputs into the model. We will be covering the more technical aspects of formula constructions and calculation methods in Chapters 10 and 11. Throughout this chapter, you will have learned not only how to structurally develop the outputs but also the methods of eliciting the right response from the sponsor to help you develop the financial model. There is a clear suggestion in this chapter that the outputs are mainly for the sponsor and are presentational only. The real work is all done in the calculations. This very point is a significant junction that defines whether someone is really a financial modeler. The best practice methodology of creating outputs is not an option, so if you decide against using it in your model, you need to consider whether you are actually producing a financial model or a more general spreadsheet model.

CHAPTER

7 Model Build This chapter is concentrated on the development (physical building) aspect of a best practice financial model. We have looked at the planning and design of financial models in Chapter 5 and then went on to describe how and why we need to start the model build with the outputs in Chapter 6. Now, we will be putting together the model. There will be some overlap with the previous chapter purely because we are looking at the end-to-end build (inputs to outputs), but that’s all good. The chapter is relatively deep and, because there is so much to get through, is quite long. However, this is a critical chapter, and whatever you do, don’t skip this one. This is the point at which we will get a complete understanding of how a best practice financial model looks and feels and how you build such model. This is the core chapter because every other chapter hangs on this one. I would like to set a premise for how we will examine the building of a financial model. I believe there is no better way to learn model building, than building a real-world model replicating the full client environment and the specifications.

Setting the environment The client is in real estate management with a portfolio of 40,000 properties. The company (the client) manages all aspects of clients’ properties including looking after the gardening, day-to-day property maintenance, hardware maintenance, security, and monthly rental collections. Going forward the company believes it can create a new income stream by offering services as an outsourcer to other real estate management companies. © Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6_7

142

Chapter 7 | Model Build The real estate company has engaged a financial modeler (you) to provide them with a tool (financial model) that allows them to understand their cost based on the services. So far, they know their costs are purely on an income statement basis (profit and loss), but for them to be able to give a price to clients on performing a service, they need to know how much it cost them to provide that service. I will present a very summarized scope, requirements, and specification as the detail is not necessary for this chapter. Also, we should assume a feasibility study has previously been completed and approved by the sponsor.

The scope The scope is to deliver a financial model that allocates and apportions two years of historical data into service lines which can be forecast to five years or more into the future. The sponsor in the client is the senior financial controller who will oversee the delivery of the model.

The requirements and specifications The financial model will need to confirm to the following requirements and specifications: ·· The model must be delivered as an Excel tool. ·· The model must contain data and be fully operational. ·· The model should contain all necessary instructions on use. ·· The model must reconcile with the reported financial. ·· The model must provide transparency to the key drivers of the services. ·· The model must be delivered within two months. ·· The model will be built by one financial modeler, and there are no other resources available. These are an abridged requirement, but they do capture the environment on where the model will need to be delivered.

Step 1: Deciding the type of model From the outset, we need to decide what type of model we will be building. In Chapter 2, we looked at the several accepted types of models that are used in a specialized environment. The selection of the type of model will depend largely on the industry that is going to be built, the requirements, and the modeler’s experience.

The Handbook of Financial Modeling The model we are going to build does not confirm to any particular industry; in fact, it is not certain if there is a particular model available based on the specification. This would therefore a hybrid model, a model that is designed and built based on the project requirements and lend itself to using a broad range of modeling techniques. We can broadly call the model we will build a cost allocation model, in that we are capturing actual costs and reallocating these costs a number of buckets decided by the client company. We will therefore be building a one-off model using best practices along the way. The requirements are giving us hints to some particular modeling techniques that we will need to incorporate. I won’t go into detail with these techniques at this stage but will point the techniques as we will use them further in the chapter.

Step 2: Creating the worksheet template As much as possible when starting on the model build in Excel, you should aim to have a consistent look and feel for every worksheet. The most efficient way of achieving this is to create a template worksheet as your first task. This sheet will standardize the color, the fonts, and the header for every worksheet. Never have a worksheet that does not have the header information, because this creates a sense of unprofessionalism for the model user. Also, the model can become confusing if some of the worksheets have header and some don’t. The impression it gives is apathetical attitude to model. The template does not need too many elements, but like in Figure 7-1, we need a certain information to be included.

Figure 7-1.  A template worksheet is the first physical worksheet to create

143

144

Chapter 7 | Model Build The template should include a number of items at the top, including the file name, the client, the name of the worksheet, and the version of the model. The order which these appear is not important; however, having these items on the template will ensure every worksheet thereafter is uniform. You may wonder why we need these details. The reason stems more from the way Excel as an application is designed when it’s first opened. Usually, when you open an Excel Workbook, it will open up showing the worksheet that was last saved by the previous user. Ordinarily this is not a problem; however, with financial models, it’s quite possible to have several worksheets in the file all having a specific purpose. We need some way to alert the person who opens the model to know where they are in the workbook and also to quickly understand whether they have the correct version or the right client for that matter. This may seem a little like overkill, but as a modeler, having headers on each worksheet should be standard practice. If you avail yourself to making sure you have these headers, before long you will find it becomes automatic, and you will wonder why you never did it. Each of the elements in the header is based either on some formula or a link to a control worksheet as in Figure 7-2.

Figure 7-2.  The file name is a formula that can be applied once and used on all other worksheets

You will notice in Figure 7-2 the file name is a formula using a series of text, filename (), and find () functions. This is a useful formula construction that you can write once and then store in your modeling toolbox (a modeling toolbox is an Excel file in which you collect formula and coding instructions for reuse) to use again. The function description is such =MID(@CELL("Filename",$A$1),FIND("[".CELL("Filename",$A$1))+1,FIND("]", @CELL("Filename",$A$1))-FIND("[",@CELL("Filename",$A$1))-1)

This rather long and convoluted formula is not as daunting as it seems and is really quite simple. Its saying looks for the full extension of where the file has been saved to and when you find the [and] symbols, take the values between those simples, and make them into text.

The Handbook of Financial Modeling Now, those of you who have been paying attention will recall that in best practices, we make a particular reference to avoid a long and complex formula. So yes, I am guilty of breaching best practices; however, there is one mitigation that must be considered. The header information, while it’s part of the financial model, is actually purely for labeling and orientation; in other words, these formulas do not work on the model data. In such case, if you decide you want to automate labels, then it’s fair to use which ever technique works so long as there is no interference with the workings of the model. The headers in rows 3 and 4 are much the same as in Figure 7-3; they use a version of the preceding formula construction. However, the header in row 2 is different.

Figure 7-3.  The formula to capture the template name

You can see in Figure 7-4 the range name called Client which the header is linking to.

Figure 7-4.  The client name uses a range name not a formula

Naming a range is a concept in spreadsheets where you can give an individual cell or an array (range) of cells a name which is familiar to you. Then, going forward when you need to refer to that cell or range, all you have to do is call it by typing in the name you gave. I won’t be covering how to create range names in this book, but surmise to say, there are plenty of good sources on the Web and a number of books by Apress that describe range naming. At this point what I will tell you is that there is a worksheet called Control which I will cover shortly the administration details concerning the model. This control worksheet is where we list the client’s name and create the range name.

145

146

Chapter 7 | Model Build

Step 3: Create the model style worksheet Each model you create will need to have a worksheet called styles. The style sheet is an informational worksheet that provides visual clues for the user as to the color conventions used in this particular model. We use differentiating colors in financial models to make the model user aware of which cells are for inputs, which are calculations, or which are drop-down lists or cells with links to external files as in Figure 7-5.

Figure 7-5.  The style gives clues to the modeling convention of the model

Notice that the style sheet is created straight after the template and is therefore one of the earliest worksheets of the model. There is a good reason to having style sheet developed early. Once you develop the styles, make sure you use them by always referring back to the worksheet. So what I mean is that you have to use a particular shade of yellow to signify inputs and make sure you don’t then use the Excel color picker on your inputs because you may choose a different shade of yellow, causing all kinds of confusion to the model styles. Always go back to the style worksheet and apply the paste brush to the style you need.

The Handbook of Financial Modeling

Step 4: Time for some control You need to create the control worksheet next as in Figure 7-6. This control worksheet should contain administration information about the model such as the name and contact details of the sponsor, the client’s name, and details of the model users. Think of the control worksheet as being for the model developer (modeler); it’s not so much an operational part of the model and hence the use of word control.

Figure 7-6.  The control worksheet has several details about the model

In addition, the control worksheet also has the methods by which you the modeler will track the versions of the model during the build, confidentiality settings, and user rights checks. The control worksheet should always have the details of the sponsor, the model users, any operational stakeholders, and the model as in Figure 7-7.

Figure 7-7.  The control sheet has information used across the entire model

147

148

Chapter 7 | Model Build The control worksheet supplies information to the headers in the shape of version numbers and also supplies information to the cover sheet like the model service description and scope as in Figure 7-8.

Figure 7-8.  Much of the details in the control worksheet will go to the cover worksheet

One very important information contained in the control worksheet is the model development history (Figure 7-9). The development of the model is critical to maintaining the version control. The modeler should list all the parts of the model that have been updated or added and then save a copy of the model with an incremental version code.

Figure 7-9.  The development history should show incremental changes to the model by development implementation

The Handbook of Financial Modeling This means should something catastrophic happened within the model, the modeler always has access to the last known good copy and will know which parts of the model failed. For the most part, financial models are in some way or another confidential because the information and data held in the model are proprietary. You need to build a confidentially setting into the model in the control worksheet. In Figure 7-10, the confidentiality is built using a list of confidentiality levels and applied to a data validation dropdown list in Figure 7-11.

Figure 7-10.  The confidentiality is made from a list within the control sheet and applied with a drop-down list

149

150

Chapter 7 | Model Build

Figure 7-11.  The confidentiality uses a data validation list on a range name in the control worksheet

In our model the requirements are quite specific that the model wonder will the senior financial controller. So, we need some method of making sure there is a warning produced if some, other than the person authorized to use the model, opens the file. We can create a simple logging warning, which uses the username of the machine being used as in Figure 7-12.

Figure 7-12.  The username is accessed and checked against a list of authorized users; in this case, all is okay

The Handbook of Financial Modeling The login routine checks the username against a prepopulated list of authorized users; if there is a match, then no errors are raised; if there is no match, then a warning will be raised in the financial model.

Step 5: Create the model cover worksheet The cover worksheet (Figure  7-13) is the starting point of the workbook. Often, modelers will create a Visual Basic for Applications (VBA) script so that when a financial model Excel file is opened, the first sheet to appear is the cover sheet irrespective of how the last user closed the model. I will broach the topic of VBA and whether it should be used in the model later in the book, but for now, I can advise that having a cover sheet that is the first point of call is always a good start.

Figure 7-13.  The cover worksheet

The cover sheet is really a worksheet that is linked to the control worksheet. There are no input elements in the cover sheet because it’s designed purely to give an introduction to the model.

151

152

Chapter 7 | Model Build The cover worksheet can have any number of information, but always make sure the four-core information is always included which are ·· The name and contact details of the model project stakeholders, including the sponsor, operational owner(s), model owner, and the financial modeler who is building the model. ·· A brief description of the model, possibly why it’s been commissioned and a narrative of the service the model will perform. ·· An error check message for the whole model. As this is the first worksheet the users will see, they need to understand if the model has opened with any errors. ·· The end of the worksheet may seem a trivial matter, but make sure you always place a visual band to show that there is no longer any more information beyond the band in the worksheet. Remember there are over one million rows in Excel, and if there is any data placed in anyone of cells below the cover sheet that is critical to the model, users could potentially delete it. So, make them aware when where the worksheet ends.

Step 6: Build your timeline template The scope of the modeling project includes the ability to not only take historical financial data but also to forecast into the future for five or more years. This is our hint that the model we build must be capable of managing timescales. Although a five-year forecast is scoped, we need to build the model to the lowest timescale possible. In this case we should use months; there is no reason to use anything smaller like weeks or days, as that would just make our model far too large and difficult to manage. Before we can start to look at our inputs and calculations, we must put together a timeline template in the model. The timeline template should be designed to dynamically move with the changes in dates. For instance, if the model user chooses to start using the model in January 2021, then they should be able to use that date, and the timeline in the model will adjust to forecast from that date and also take historical data. Conversely if the model user chooses to start the model from September 2022, we need to make it easy to just change the date and not worry about the model adjusting. In Figure 7-14, the template has been built as the timeline worksheet.

The Handbook of Financial Modeling

Figure 7-14.  The timeline template

Our timeline template starts with a list of months which we can be seen in row 10  in Figure  7-15. These months are static inputs which the user can change; we use this list to allow the user to decide how they want the months of year to be labeled such as Jan or January or any other label they choose. The timeline will always use the label from the model user to label all the timelines in the entire model.

Figure 7-15.  The months are flexible and can be tailored to the model user’s preferences

The timeline template should then have a section that captures all the types of timescales that can be applied to a month. This may seem confusing, but think of it like this, if we have three months January, February, and March, how many ways can these three months be represented? There are several ways such as ·· Period 1, 2, 3 ·· Month 1, 2, 3 ·· Quarters Q1, Q1, Q1 ·· Years Month1 Year 1, Month2 Year 1, Month3 Year 1 ·· And so on

153

154

Chapter 7 | Model Build The month timeline is where we create all the possibilities of timescales and then tie them down to the dynamic of the timeline which you can see in Figure 7-16.

Figure 7-16.  We capture as many month timescales as possible and link them to the start date to be dynamic

This means we can, with the timeline setup, call on any of the timescales in Figure 7-15 (such as from, To, Period, Month in year, Quarter) anywhere in the model and use them without worry about changing the time labels manually. In Figure 7-17, the formula constructions for each of the cells are shown just for you to get an idea of how we are creating this timeline. Don’t worry too much about understanding the formula, because we will cover most of these formulas and how to use them in Chapter 11.

Figure 7-17.  The formula to create the month timeline

The Handbook of Financial Modeling

Step 7: Inputs, set up the constants We come to the inputs which should be set up following only after all the steps we have covered. Often, in financial models, you will be confronted with a situation where you have more than one type of input. This may seem strange after all an input is an input right. The question you have to ask yourself is one of these: do my inputs variable or are they fixed or both? Are the inputs based on scenarios? Are my inputs coming from a data source? At the end of these questions, if you find you do have inputs that vary in the way they will be used, then you need to think about splitting them and creating separate input worksheets. A clue to you is that just about every financial model will have more than one type of input. These will likely be variable inputs which are largely based on assumptions and fixed inputs which are based on the business infrastructure such as the number of departments. Figure 7-18 is a worksheet which has the fixed inputs which we call the constants.

Figure 7-18.  The input worksheet which contains the fixed elements is the constant

There are a number of inputs we can look at so that you can get an understanding look how and why we need them. The details about the project which are in part used in the worksheet headers are the constants as in Figure 7-19.

Figure 7-19.  The project details are the constants as they are fixed inputs

155

156

Chapter 7 | Model Build The project details are an example of an input which once typed should not change or certainly not frequently. In Figure 7-20, we have several inputs for aspects such as currency used, end of worksheet markers, number of months in the year, and so forth. These are miscellaneous inputs because they are not produced by any assumption but are generally a matter of fact. Notice in Figure 7-20 at the end of each input there is a name in italics.

Figure 7-20.  All miscellaneous inputs belong in the constants worksheet

This is the caption of the range name associated with that particular input. It’s a good practice to try as much as possible to actually write out the range name next to the cell or array so that anyone using the model can quickly identify a cell to a range name. A very important part of the constants worksheet are the dates to set the model. In Figure 7-21, we have an input for start date which is the date when the model should operate from.

Figure 7-21.  The model dates for the model are set

Do not be confused the model start date with the data and information dates. The start date is independent of any data; it is merely a starting point from which we can set the timelines working. In this instance as you will see from the arrows in Figure 7-21, there is an error check set on the service start date, to check if the date input is too unrealistic (i.e., ten years into the future). The modeler can decide exactly how these date checks can be set up, but my advice is that when you expect a user input into data field, always have checks because this date is critical to how the model will interpret the outputs and any issues on the date will circulate right through the model.

The Handbook of Financial Modeling In our constants, we have included any business infrastructure inputs which we see as being a once-only input as in Figure 7-22 where we have put inputs for the company’s financial reporting year.

Figure 7-22.  The company’s financial reporting year is critical to getting the outputs into the correct year

The user can implement and input whatever financial reporting years they wish so long as they provide a reference year number (on the right in Figure 7-22). One point for you to note is that if you look back at Figure 7-21 in the project dates, you will see Company year start and Company year end with the dates. These dates are completely dependent on the company’s financial year in Figure  7-22. They use the reference year to discern which financial year the model is currently residing in.

Step 8: Inputs, create data input template Not all financial models will include historical data; however, all models that require some forecasting ability will need historical information. So even if the requirements do not state the need for historical data in the model, just remember if the outputs are forecasting into the future, you need historical. In our model we must have historical data, and therefore we need a template to collect this data from wherever it comes from as in Figure 7-23.

157

158

Chapter 7 | Model Build

Figure 7-23.  The historical data worksheet is also an input sheet

There are a number of things a modeler should always look out for when dealing with data that will come into the model: ·· When building the financial model, the modeler is the owner in the said model. Make sure you are clear to all stakeholders that nothing enters in that model unless you are happy with it. Remember the buck stops with you! ·· Make sure you are clear on which attributes of the data you will need to load into the model and communicate this to the person responsible for providing the data. ·· Be prepared to put some significant time in days in your project for you to spend on cleaning the data. Data always needs cleaning. ·· Always ask you sponsor to give you a status of the quality of the data that you will need, such that does it need any intervention from you. You will find no matter what the sponsor says you will need to intervene, it’s worth seeing how the sponsor views his data. ·· Never ask to receive data directly into data input template. Stage the data in a CSV file remotely and then do the data cleansing in that file. Then, import the cleansed data from the CSV to the model. ·· Always make sure when you are cleansing data you have a copy of the original data, and you have marked the revisions in the second copy of the cleansed data so that there is an auditable trail of what you have done.

The Handbook of Financial Modeling You will see in Figure 7-23 that some additional columns have been added at the end of the data. These are tags. We attach the tags to each row of the data, which allows us to create multiple lookups against each row of data. For instance, by adding these tags, we can create very detailed lookups that can be based on allocation type and/or Cost marker and Reference (which can be Dept code, Account code, Account periods, Financial Year, and MGT code). You should note that structurally the data template feeds into the calculations (workings template) and does not feed into any of the other input worksheets.

Step 9: Inputs, create scenario inputs Scenarios are actions or combinations of actions that test how the model will react once they are activated. They derive the scenario from the sponsor and then create the scenario for the model. One point that is important is that the modeler is not the ultimate creator of the scenarios but the middle person who develops them into the model. If the sponsor has not stipulated any scenarios, then the model will not have any. I make it a point to always ask the sponsor during the requirements gathering if they are expecting to have scenarios. This way, the model can have a ready-made template as in Figure 7-24. There can be a few things that irk us when a sponsor decides they want scenarios after the model has been built. It simply isn’t possible to just plug scenarios into a model; they must be built into the whole model design.

Figure 7-24.  The scenario template

There are a number of scenarios we can build into an input worksheet such as flexing the changes in real estate property quantities and the mix of property types as in Figure 7-25.

159

160

Chapter 7 | Model Build

Figure 7-25.  The real estate portfolio has been made into a table to allow flexing of the property mix

Just as the other inputs’ worksheets, the scenario will feed directly into the workings without passing through any other input worksheet. There are other scenarios that are set up in the worksheets including the one for new future initiatives (Figure 7-26) and also scenarios surrounding inflation in Figure 7-27.

Figure 7-26.  A scenario setting for any new initiatives that may be taken in the future

Figure 7-27.  A scenario to take care of changes in inflation rates year on year is always very useful

The Handbook of Financial Modeling

Step 10: Inputs, allocations We need to understand the type of financial model we are building. At its heart this model is all about allocations and redistributing costs into activities and services. Although we have had three different inputs to cover all fixed, data, and scenario, we still one more to create. We need a template that allows the model to allocate cost. Now, this allocation input is not a standard input but a specialized specific input for this model which can be seen in Figure 7-28.

Figure 7-28.  The input template to allocate and redistribute cost activities and services

We have three methods of allocating historical costs and mapping those costs into forecast. We are using employee job titles (1) and headcount (2) and the activities performed (3) which we call salaries. The second method uses the department where the cost incurred matched up to the activities in those departments called direct. The third method uses location where the cost was incurred matched up to activities in those locations which is called location. The allocation template therefore used three methods for reallocating costs, which will then allow the client to pick when which method (salary, direct, location) produces the more appropriate results to the company. Needless to say, the allocation worksheet although being an input is really a base template that should not require any further changes or updates.

161

162

Chapter 7 | Model Build

S tep 11: The calculations (workings) worksheet The working worksheet is simply the sheet that collects every single input (variables) for all four input worksheets and then ties up the variables with one another. The workings are where the particular business rules for the client company will be applied, and further the modeler needs to demonstrate their outright understanding of a number of business logics. For example, how does a financial modeler calculate the effects of inflation in the working, or how is amortization treated in a cash flow? Unfortunately, these are not easily taught as they come from experience of modeling and many different environments and trying things and seeing if and how they work. Building the workings is totally dependent of the financial modeler’s experience and skills; however, we will cross a bridge because this book has been designed to give you that experience and skill. The workings should be organized from the top down applying each of the variables from the inputs stage by stage rather than like layers working down the worksheet as in Figure 7-29.

Figure 7-29.  The worksheet that brings all the calculation of variables from the inputs

The Handbook of Financial Modeling The workings will always include the timelines at the top of the worksheet and then will bring in each of the inputs a starting point as in Figure  7-30 where the properties from the constant inputs have been brought in.

Figure 7-30.  The start of inputs is brought into the workings using the properties from the constant inputs

As mentioned earlier we need to also make sure the timescales in the workings are aligned to the timescales in the timeline worksheet which we can see in Figure 7-31.

163

164

Chapter 7 | Model Build

Figure 7-31.  The timescales in the timeline and workings worksheet all start in the same column (column K)

There is a good reason why we should have the timescales aligned into the same columns in our workings and timelines. When we use range names if the columns are aligned, then we only need to call the name of the range name (which was set up in the timeline worksheet) in the workings, and all our dates will be matched. This not only saves time but also ensures mistakes with dates being in the wrong cells are eliminated. We can now set up the workings in sections applying each of the input variables like a list in Figure 7-32 until we reach the point where all the input variables have been applied.

The Handbook of Financial Modeling

Figure 7-32.  The workings are organized in sections working down the worksheet until the final outputs have been calculated

165

166

Chapter 7 | Model Build Notice in Figure  7-32 the “+” sign in the left of rows. This is a grouping function in Excel. It signifies that under each name in the list, there are several rows of data. So, for instance, in Figure 7-33, we have the labor and salaries section ungrouped, and we see the inputs that are being used and calculated.

Figure 7-33.  The ungrouped list for labor and salaries also shows the use of the SUMIFS() function

One of the most widely used functions in the workings is the SUMIFS () which will be explained in detail in Chapter 10. Once all the sections are calculated and completed, we can then amalgate these calculations into the final section which is a draft copy of the outputs like in Figure 7-34.

Figure 7-34.  The consolidation of all the calculations into one section ready to be linked into the outputs

The Handbook of Financial Modeling By using the working sheet on a layer-by-layer basis, with sections like in Figure 7-32, we can then work through the calculations methodically with a structure that allows us to track how each section and each input variable interact in the model. This is the best practice for calculations, and you should follow this type of structure at every opportunity in the workings worksheet.

Step 12: Create error checking Throughout all the input worksheets and the workings, we should be creating routines to check for errors. In the input sheets, the types of errors to check are those that involve typing in values that are outside of the expected parameters, for example, if an input is asking to calculate the annual bonus and it wants to know how many months are there in the bonus period, you would create an error check to detect anything below 0 and anything greater than 12. There is no such thing as too many error checks in a financial model; the only exception is to just make sure they are actually trying to trap a logic problem. Error checks would normally be placed at the end of the column or row where there are inputs in between or can also be placed next to a single input cell. Different modelers will use their own preferred visual representation; I prefer to use the system TRUE (Green), No error; FALSE (Red), Error; and WARNING (Amber), Warning because it conforms to a well-established rating used in project management (RAG) and is therefore visually intuitive. To make the error check transparent, the model creates an error check worksheet as in Figure 7-35. This worksheet collects the cumulative checks from all the worksheets with error checks and then turns them into a global model status.

167

168

Chapter 7 | Model Build

Figure 7-35.  The error check worksheet

The beauty of the error check worksheet is when an error appears in the worksheet, and if the user looks at the error check worksheet, they immediately see which worksheet is causing the error to disrupt the whole model. Not all financial modelers use an error check worksheet, but I suggest you get into the habit of always making one and using it, because not only does it help to trap errors but it also allows the user of the model to quickly see if an input they have just put through is the cause of the issue.

Step 13: Build in the documentation We should always build up a dictionary of the model with every model. This is literally a brief description of the purpose of each worksheet and the types of inputs therein much like in Figure 7-36. The worksheet for these notes can be created much earlier. I often create these notes just before the constants worksheet, and then I add documentation as I go along with the model building.

The Handbook of Financial Modeling

Figure 7-36.  The documentation worksheet and notes

Step 14: Added-value modeling This final step is optional and not always necessary. I refer to it as added value because this is where you can use your modeling experience to give the sponsor something additional to their requirements. You may be wondering why would bother to go beyond the requirements? It’s all about exceeding the expectation of a client because it sets up a favorable situation for the future. A client who is happy with your modeling is a client who is more likely to be a client throughout your modeling career. However, it is not only the enhancement of client relationships that you need. I use the added-value time to try out new things; it’s an opportunity to see if you can implement something into the model that can be useful in your future modeling. For instance, in many of the models, I will place an audit feature much like that in Figure 7-37.

169

170

Chapter 7 | Model Build

Figure 7-37.  The audit worksheet is an example of added value

This worksheet allows the user to have confidence on how the model has changed since they last opened it because if records changes in the data and date stamps them. You see often with financial models that they are kept on a general server where people can open and use them and mess around with the inputs. The ability to know when that has happened is valuable to a client. There are other added-value additions that you can routinely add to all the financial models like having an index page with links for navigations to worksheet as in Figure 7-38.

The Handbook of Financial Modeling

Figure 7-38.  Index page for navigation can be a nice touch to a financial model

Another very useful feature and something that clients will always like is to add a dashboard, one that easily summarizes the information from the outputs and uses graphical objects. Don’t overlook the effect of a good dashboard; often, it can sell a model just by itself. In Figure 7-39, I have shown an example of how switches have been included to turn ON or OFF features in the model and see their effect on the model.

171

172

Chapter 7 | Model Build

Figure 7-39.  An example of how to implement a dashboard

Conclusion Building a model need not be complex once you decide to follow a method. You should always have in your plan a summary of the steps much like we have on this chapter, but steps you will take to build the model. Having these preplanned steps will not only ease the model building, it will also allow you to quickly evaluate whether you have missed anything. I have purposely left out showing you a complete model, because although I have your steps, we have not yet seen the formula and coding side. We will see a number of full financial models in later chapters.

CHAPTER

8 Financial Modeling and Accountancy The products of a financial model are the outputs, which in the majority of model are financial. At the end of the day, modeling is really about putting together a clutch financial analysis and statements that have had an acute level of rigor applied to them. This way, they offer the best possible representation of the real world as you can get. Simply put, all financial models have financial outputs, of which the majority should be familiar to modelers. Figure  8-1 shows many of the financial statements and ratios that are typical in financial models. One of the required skills of a financial modeler is the ability to distinguish and select the most useful and fitting statements and then use them in a way that will give an accurate story about the project.

© Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6_8

174

Chapter 8 | Financial Modeling and Accountancy

Figure 8-1.  The majority of financial statements used in financial models

Experience suggests that in the majority of financial models, the core of most of the outputs incorporates the elements of their financial statements: ·· Income statement (also called the profit and loss or revenue statement) ·· Cash flow statement ·· Balance sheet Typically, all financial modelers will be very conversant with the main financial statements to the extent that they are able to create them from scratch and then communicate them effectively to interested parties. These three statements also make up the foundation to most of the financial ratios; therefore, they cannot be ignored. Financial statements and their analysis are very powerful tools in the hands of someone who understands them. This is a key point to understand because they offer insights into an organization or project that would otherwise be unclear. This point is one that all modelers need to understand. Financial modelers have a responsibility to produce the outputs and to ensure they are in accordance with any statutory requirements. They should be confident and assured that the outputs give as best a representation of the financial health of whatever is being modeled. There should be no question about artificially altering or fudging these statements to give an alternative representation.

The Handbook of Financial Modeling On occasion, I have been subtly asked to change the financial statements, to slant them toward a given goal. The stock answer to this is always, unequivocally, “no.” My advice to any modeler is that you do the same. Accountants are bound by professional ethics stipulated by their associations; they are also in a position of responsibility which means there are strict legal obligations to adhere to. Financial modelers, while not having an associations ethics put on them, are in a position of responsibility with the result that manipulation is tantamount to fraud. It’s always best to steer well away from anything that would change financial statements because of potential repercussions. But if you should find yourself backed into a corner and have no alternative but to fudge the numbers, my advice would be to reflect the changes or fudges on the assumption register and include the detail of who requested these changes. Follow this step by creating a second set of outputs, identical to the first in everything but the fudged numbers, which should be clearly labeled with the owner of the adjustment. Although this is more work and could delay completing the model, constantly use this procedure when you have outputs that have external influences. By having two sets of outputs, there will be one set of the base outputs that have not been adjusted and another set of the alternative outputs that have been altered.

Accounting primer This section will cover basic accounting. If you have no formal accounting background, it is an essential foundation for understanding financial statements. Even if you are familiar with basic accounting principles, it will be useful for you to look through this section and reacquaint yourself with some of the accounting fundamentals.

The need for accounting Every organization should maintain sound records to keep track of such questions as the following: ·· How much money does the organization currently have? ·· How much did the organization used to have? ·· Where does the money come from? ·· How is the money being spent? ·· Where is the money being spent?

175

176

Chapter 8 | Financial Modeling and Accountancy Keeping track of these questions will provide answers that will then be used to assess the strengths and weaknesses of the organization. Answering another set of questions like the following will help identify the strengths and weaknesses: ·· Is the business making or losing money? ·· How much is the business worth? ·· Does more money need to be put into the business? ·· How much money is owed to the business? ·· How can the business change the way it operates so that it can make a profit or even more profit? As the financial modeler or accountant, you will be required to provide the valuable information needed to assist management in the decision of tackling these questions.

Accounting and business Accounting is a system used in business and commerce to measure financial performance by noting and classifying all the transactions, such as sales, purchases, assets, and liabilities, in a manner that adheres to accepted standard formats. It allows the audience to evaluate a company’s past performance, present condition, and future prospects. By far, the main exponents of accounting and creating financial statements are business organizations. Although the detail structure of organizations may vary from country to country, most of the world still works under these three structures: ·· Sole proprietorships ·· Partnerships ·· Corporations

Sole proprietorships A sole proprietorship is a business that is wholly owned by a single individual. It is the easiest and the least expensive way to start a business, often associated with small “one-person”–type businesses. The advantage of the sole proprietorship is that it is relatively free from red tape and legalities that restrict other forms of business. Its major disadvantage is that it comes with unlimited liability. The owner and the business are regarded as the same from a legal standpoint, which means a legal issue from business will also have a

The Handbook of Financial Modeling detrimental effect on the individual’s personal status as well. Very few large organizations are sole proprietors because aside from the legal constraints, structurally it is virtually impossible to expand and still operate efficiently.

Partnerships A partnership is a legal association of two or more individuals called partners who are coowners of a business for the purpose of making a profit. Like proprietorships, they are easy to form. This type of business organization is based upon a written agreement that details the various interests and rights of the partners. It is always advisable to seek legal advice and document each person’s rights and responsibilities. There are three main kinds of partnerships: ·· General partnership ·· Limited partnership ·· Master limited partnership

General partnership A general partnership is a business that is owned and operated by two or more persons where everyone has a right as a coowner and is liable for the business’s debts. All partners report their share from the partnership profits or losses on their individual tax returns. The partnership itself is not responsible for any tax liabilities. The partners also report their share of partnership profits or losses on their individual tax returns and pay the tax on those profits. The partnership itself does not pay any taxes on its tax return.

Limited partnership In a limited partnership, one or more partners run the business as general partners. The remaining partners are passive investors who become limited partners and are personally liable only for the amount of their investments. They are called limited partners because they cannot be sued for more money than they have invested into the business.

Master limited partnership Master limited partnerships are related to corporations in that they can trade partnership units on listed stock exchanges. They have many advantages that are similar to corporations, such as limited liability, unlimited life, and transferable ownership. In addition, these partnerships have another rewarding advantage if 90% of their income is from passive sources (e.g., rental income). If this is the case, then they pay no corporate taxes since the profits are paid to the stockholders, who are taxed at individual rates.

177

178

Chapter 8 | Financial Modeling and Accountancy This type of partnership has several of the same benefits of sole proprietorship, particularly with new investment. If more capital is required, it’s quite possible to attract a new partner who is required to put up the required capital investment. One of the concerns of this partnership is how long the business runs. It is dependent on the partners, and therefore disputes, ill health, and death can all dissolve the partnership.

Corporation Corporation is the general term for legally chartered enterprises with legal rights rather like a person. Therefore, a corporation is able to buy and sell goods and services, engage in contracts, sue and be sued, and pay taxes. A corporation can have different names depending upon the country, but they all essentially have the same basic structure. The corporation is the most dominant form of business organization worldwide. Since the corporation exists as a separate entity apart from an individual, it is legally responsible for its actions and debts. The strength of a corporation is that its ownership and management are separate. In theory, the owners may get rid of the managers if they vote to do so. Conversely, because the shares of the corporation, known as stock, can be sold to someone else, the corporation’s ownership can change drastically, while the management stays the same. The corporation’s unlimited life span coupled with its ability to raise money gives it the potential for significant growth. A company does not have to be large to incorporate. In fact, most corporations, like most businesses, are relatively tiny. The majority of small corporations are privately held. One disadvantage of corporations is that they suffer from relatively higher taxes than unincorporated businesses. In addition, shareholders must pay income tax on their share of the company’s profit that they receive as dividends. This does mean the same pool of income is taxed twice, once at corporate and a second time on the individual. There are several different types of corporations based on various distinctions, such as how they raise capital. Private corporations, while having shares, are limited in how those shares in the company can be bought and sold. The nonprivate companies, which are called public corporations, can sell and buy shares on the open market. Their shares are listed in public indices with the price per share. Professional corporations are set up by businesses whose shareholders offer professional services (legal, medical, engineering, and so forth). This allows them to set up beneficial pension and insurance packages.

The Handbook of Financial Modeling There is also a limited liability company (LLC) which combines the advantages of companies (corporations in the United States that pass profits and losses through to owners) and limited partnerships without having to abide by the restrictions of either. LLCs allow companies to pay taxes like partnerships and be protected from liabilities beyond their investments.

Types of accounting There are two methods of tracking accounting records: ·· Cash-based accounting ·· Accrual accounting

Cash-based accounting Most of us use this cash method to keep track of our personal financial activities. The cash method recognizes revenue when payment is received and recognizes expenses when cash is paid out. For example, your personal bank current account is based upon the cash method. Expenses are recorded when cash is paid out, and revenue is recorded when cash or check deposits are received.

Accrual accounting The accrual method of accounting requires that revenue be recognized and assigned to the accounting period in which it is earned. Similarly, expenses must be recognized and assigned to the accounting period in which they are incurred. A company tracks the summary of the accounting activity in time intervals called accounting periods. These periods are usually a month long. It is also common for a company to create a yearly statement of records. This annual period is also called a fiscal or an accounting year. The accrual method relies upon the principle of matching revenues and expenses. This principle states that the expenses for a period, which are the costs of doing business to earn income, should be compared with the revenues during the period, which is the income earned as the result of those expenses. In other words, the expenses for the period should accurately match up with the costs of producing revenue for the period.

179

180

Chapter 8 | Financial Modeling and Accountancy In general, there are two types of adjustments that need to be made at the end of the accounting period. The first type of adjustment arises when more expense or revenue has been recorded than was actually incurred or earned during the accounting period. An example of this might be the prepayment of a two-year insurance premium for $2,000. The actual insurance expense during the year would be only $1,000. Therefore, an adjusting entry at the end of the accounting period is necessary to show the correct amount of insurance expense for that period. Similarly, there may be revenue that was received but was not in fact earned during the accounting period. For example, the business may have been paid for services that will not actually be provided or earned until the next year. In this case, an adjusting entry at the end of the accounting period is made to defer, or postpone, the recognition of revenue to the period when it is actually earned. Although many companies use the accrual method of accounting, some small businesses prefer the cash basis. The accrual method generates tax obligations before the cash has been collected. This benefits the government because the IRS gets its tax money sooner.

Cash vs. accrual accounting When a business bills a client or customer, that business will experience an increase in its income (not cash) in paper asset. The transaction will be reflected in the income statement. The increase will also trigger an increase in the accounts receivable. When the business is paid by the client, the paper asset now turns into money, which is placed into the business bank account and becomes a tangible asset (it’s now cash). Through a process of recording the payment and the deposit, accounts receivable decreases and the bank balance increases. This system is based on an accrual such that the accounts receivable is an asset that is owed to the business. However, the business does not have money in the bank or property to show that it has any ownership other than an invoice, which is shown in Figure  8-2. It only exists on paper assets. It grows or accumulates as the business issues invoices; consequently, accounts receivable is part of an accrual accounting system.

The Handbook of Financial Modeling

Figure 8-2.  The creation of an accrual

A cash accounting method only counts income when money is received. It does not keep track of accounts receivable, which means there is a direct compensation between the customer and vendor, as in Figure 8-3.

Figure 8-3.  The cash accounting does not have accounts receivable as it takes cash directly

181

182

Chapter 8 | Financial Modeling and Accountancy You may be wondering how you would choose which one to use. In reality, small businesses tend to use both methods without realizing the difference until income tax time when they use an accounting general ledger item to manage their finances or bring pass their ledgers to the accountant. This general ledger (GL) system can handle both accrual and cash-based accounting. Almost all GL systems will allow users to create a setup where they can choose which type of accounting method to use. By and large, most businesses today use some kind of GL system for their accounting.

Accounts Accounting systems (they have GL at the core) use accounts to keep track of information. Consider this simple way to understanding accounts. On your computer office, there is some method of viewing information usually called explorer or finder. In this explorer, you have multiple file folders, and each file folder has information of the data it holds, for example, some folders may hold images, documents, system details, and so on. In accounting, these folders are called accounts and are given very specific labels pertaining to the type of data they will hold. A chart of accounts is a list of all the accounts and the code that has been given to each them (account code). Accounts keep track of money spent, earned, owned, or owed. Each account keeps track of a specific topic only. For example, the money in your bank or the checking account would be recorded in an account called “cash in bank.” The value of your office furniture would be stored in another account. Likewise, the amount you borrowed from a bank would be stored in a separate account. Each account has a balance representing the value of the item as an amount of money. Accounts are divided into several categories, such as assets, liabilities, income, and expense accounts. In theory successful business will have more assets than liabilities, although reality does prove the converse can be true also. Income and expense accounts keep track of where your money comes from and how it is spent. This helps make sure you always have more assets than liabilities.

Account types In order to track money within an organization, different types of accounting categories exist. These categories are used to denote if the money is owned or owed by the organization. In these next sections, I will discuss the three main categories: assets, liabilities, and capital.

The Handbook of Financial Modeling

Assets An asset is a property of value owned by a business. Physical objects and intangible (does not have physical substance) rights—money, accounts receivable, merchandise, machinery, buildings, and inventories for sale—are common examples of business assets because they have economic value for the owner. Assets are listed on a balance sheet according to the ease with which they can be converted to cash. They are usually divided into three main groups: ·· Fixed ·· Current ·· Intangible Fixed assets Fixed assets refer to tangible (physical and measurable) assets that are used for the business. Commonly, fixed assets are long-lived resources that are used during the production of finished goods. Examples include buildings, land, equipment, furniture, and fixtures. These assets are often included among the title property, plant, and equipment that are used in running a business. The following four qualities are usually required for an item to be classified as a fixed asset: ·· Tangible ·· Long-lived ·· Used in the business ·· Not available for sale Certain long-lived assets such as machinery, cars, or equipment slowly wear out or become obsolete. The cost of such assets is systematically spread over its estimated useful life. This process is called depreciation if the asset involved is a tangible object (such as a building) or amortization if the asset involved is an intangible asset (such as a patent). Of the different kinds of fixed assets, only land does not depreciate. Current assets A current asset is an asset that is either ·· Cash including funds in checking and savings accounts ·· Marketable securities such as stocks, bonds, and similar investments

183

184

Chapter 8 | Financial Modeling and Accountancy ·· Accounts receivables, which are amounts due from customers ·· Notes receivables, which are promissory notes by customers to pay a definite sum plus interest on a definite date at a certain place ·· Inventories such as raw materials or merchandise on hand ·· Prepaid expenses like supplies on hand and services paid for but not yet used (e.g., prepaid insurance) In other words, cash and other items that can be turned back into cash within a year are considered a current asset. Intangible assets Intangible assets are assets that are not physical assets like equipment and machinery but are valuable because they can be licensed or sold outright to others. They include the cost of organizing a business, obtaining copyrights, registering trademarks, securing patents on an invention or process, and valuing goodwill. Goodwill is not entered as an asset unless the business has been purchased. It is the least tangible of all the assets because it is the price a purchaser is willing to pay for a company’s reputation, especially in its relations with customers.

Liabilities A liability is a legal obligation of a business to pay a debt. Debts can be paid with money, goods, or services, but they are usually paid in cash. The most common liabilities are notes payable and accounts payable. Accounts payable is an unwritten promise to pay suppliers or lenders specified sums of money at a definite future date. Current liabilities These are liabilities that are due within a relatively short period of time. The term “current liability” is used to designate obligations where the payment is expected within the next 12 months. Current liabilities include accounts payable, notes payable, and accrued expenses. Current liabilities reflect money that is owed to people or organizations by the company, and that must be paid shortly. Accounts payable Accounts payable is are a general liability resulting from buying goods and services on credit. The goods are received, and the money for them is paid to the supplier at later date, creating the payable item.

The Handbook of Financial Modeling Suppose a business borrows $28,000 from the bank for a 120-day period. The instant the money is lent by the bank, the business incurs a liability of $28,000 plus interest. This is a note payable (must be paid back). The bank may require a written promise to pay before lending any amount, although there are many credit plans such as revolving credit where the promise to pay back is not in note form. On the other hand, suppose the business purchases supplies from the ABC Company for $15,000 and agrees to pay within 30 days. Upon acquiring title to the goods, the business has an accounts payable liability (owes the money and must make good the amount) to the ABC Company. In both cases, the business has become a debtor and owes money to a creditor. Other current liabilities commonly found on the balance sheet include salaries payable, interest payable, and taxes payable, which are all accrued expenses. These are expenses that have been incurred, but for which the bills have not yet been received.

Long-term liabilities Long-term liabilities are obligations that will not become due for a comparatively long period of time. The usual rule of thumb is that long-term liabilities are not due within one year. These include such things as bonds payable, mortgage notes payable, and any other debts that do not have to be paid within one year. You should note that as the long-term obligations come within the one-year range, they become current liabilities. For example, mortgage is a long-term debt, and payment is spread over a number of years. However, the monthly mortgage payments that are due within one year of the date of the balance sheet are classified as a current liability.

Capital Capital, also called net worth, is essentially what would be left over if you paid off everyone the company owes money to. If there are no business liabilities, the capital, net worth, or owner’s equity is equal to the total amount of the assets of the business.

Key accounting concepts There are two fundamental accounting concepts that were developed centuries ago but remain central in the accounting process: ·· The accounting equation ·· Double-entry system

185

186

Chapter 8 | Financial Modeling and Accountancy

The accounting equation To put it simply, the accounting equation keeps all the business accounts in balance. In this section, this equation will be explained in steps to clarify your understanding of this concept. In order to start a business, the owner usually has to put some money down to finance the business operations. Since the owner provides this money, it is called owner’s equity. In addition, this money is an asset for the company. This can be represented by the following equation:

Assets = owner’s equity If the owner of the business was to close down this business, he would receive all its assets. Let’s say that the owner decides to accept a loan from the bank. When the business decides to accept the loan, the assets would increase by the amount of the loan. In addition, this loan is also a liability for the company. This transaction can be represented by the following equation:

Assets = liabilities + owner’s equity Now, the assets of the company consist of the money invested by the owner (the owner’s equity) and the loan taken from the bank (a liability). The company’s liabilities are placed before the owner’s equity because creditors have first claim on assets. If the business was to close down, after the liabilities are paid off, anything left over (assets) would belong to the owner.

The double-entry system Our accounting principles are based upon a system created more than 500 years ago by an Italian monk named Luca Pacioli. Pacioli devised this method of keeping books, which is today known as the double-entry system of accounting. He explained that every time a transaction took place—whether it was a sale or a collection—there were two offsetting sides. The entry required a two-part “give-and-get” entry for each transaction. Here is a simple explanation of the double-entry system. Let’s say that you took a loan from the bank on behalf of the company for $5,000. Remember that the following equation was used in our earlier discussion:

Assets = liabilities + owner’s equity Because the company borrowed money from the bank, the $5,000 is a liability against the company. In addition, now that the company has the extra $5,000, this money is an asset for the company (it could be held in cash and therefore a current asset).

The Handbook of Financial Modeling If you were to record this information in your accounts, you would put $5,000  in an account called “loan taken from the bank” and $5,000  in an account called “cash saved in the bank.” The former account will be a liability, and the second account would be an asset. As you can see, two entries were created. The first one is to show from where the money was received (the source of the money). The second entry is to show where the money was sent (the destination of the money received). In a double-entry accounting system, every transaction is recorded in the form of debits and credits. Even for the simplest double-entry transaction, there will be a debit and a credit. In simpler terms, a debit is the application of money, and a credit is the source of money. Here are some examples to help you understand the concept of debits and credits: Example one You write a check for $100 to purchase some stationery. This transaction would be recorded as a credit of $100 to the cash in the bank account and a debit of $100 to the stationery account. In this case, you made a credit to the cash in the bank account, as it was the source of the money. The stationery account was debited, as it was the application of the money. Example two You receive $200 cash for services rendered to a client. This transaction would be recorded as a credit of $200 to the income from services account and a debit of $200 to the cash in the bank account. In this case, you made a credit to the income from services account, as it was the source of the money. The cash in the bank account was debited, as it was the application of the money. Example three You receive a $10,000 loan from a bank. This transaction would be recorded as a credit of $10,000 to the loan payable account and a debit of $10,000 to the cash in the bank account. In this case, you made a credit to the loan payable account, as it was the source of the money. The cash in the bank account was debited, as it was the application of the money. Example four You made out a payroll check to an employee for $300. This transaction would be recorded as a credit of $300 to the cash in the bank account and a debit of $300 to the payroll expense account. In this case, you made a credit to the cash in the bank account, as it was the source of the money. The payroll expense account was debited, as it was the application of the money.

187

188

Chapter 8 | Financial Modeling and Accountancy The previous examples illustrated some of the transactions that are recorded in a double-entry accounting system. These transactions are also referred to as journal entries. Your accounting application automatically creates the journal entries for you. In example one, you would create a check in the system, and on the check, you would give the expense account number for stationery. The checkbook program would then automatically credit the cash account and debit the stationery expense account.

Journals Looking at the ledger account alone, it is difficult to trace back all the accounts that were affected by a transaction. For this reason, another book is used to record each transaction as it takes place and to show all the accounts affected by the transaction. This book is called the general journal, or journal. Each transaction is first recorded in the journal, and then the applicable entries are made to the accounts in the GL. Because the journal is the first place a transaction is recorded, it is called the book of original entry. The advantage of the journal is that it shows all the accounts that are affected by a transaction and the amounts the proper accounts are debited and credited—all in one place. Furthermore, included with each transaction is an explanation of what the transaction is for. Transactions are recorded in the journal as they take place, so the journal is a chronological record of all transactions conducted by the business. There is a standard format for recording transactions in the journal. A journal transaction usually consists of the following: ·· Journal transaction number ·· Transaction date ·· Journal type (general journal, sales journal, and so forth) ·· Actual journal entries adjusting the account balances In addition to the general journal, other specialized journals contain entries from other accounting modules to track sales, purchases, and the disbursement of cash. Some of the important journals include the following: ·· Invoice journal report ·· Cash receipts report ·· Purchases journal ·· A/P journal (transactions and payments) report

The Handbook of Financial Modeling The GL system comes with sample chart of accounts already installed. If you prefer, you can modify these accounts or create your own chart of accounts. In addition, all the debits, credits, and journals are automatically maintained for you. When you create invoices, checks, and other transactions through the system, all the journal entries are created for you automatically. In this chapter, I have touched on some of the more important aspects of accounting to give you just an introduction to accounting. At some point in modeling, you will need to have an appreciation of at the very least the basics of accounting. The further you develop your modeling, the more likely that you will need to also further develop your appreciation for accounting. Many modelers are not accountants, but all modelers should have at least a basic understanding of accounting principles. My advice is that you go through the concepts in this chapter again until you feel familiar with them.

189

CHAPTER

9 The Implications of Accounting Rules for Modelers In this chapter, I will discuss an aspect of financial modeling that should never be overlooked, and that is the implications to the financial modeler of presenting financial statements. I mentioned earlier in this book that financial statements are heavily relied upon by various audiences and can have a significant influence on decision-making. While there are rules and regulations anywhere that are specifically aimed at the financial modeler, there are some implied responsibilities that if breached can have serious implications for whoever builds the model.

© Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6_9

192

Chapter 9 | The Implications of Accounting Rules for Modelers The modeler’s financial statement responsibilities The financial modeler who has produced the financial statements has the following responsibilities: ·· Understands the substance, gravity, and uses of the financial statements: While this may seem obvious, what it means is that modelers are not in a position to deny that they were unaware of the content of the financial statements. ·· Provides due care: Accountants are always aware of this responsibility; therefore, it is important that financial modelers, who are also deemed to be in a position of responsibility, should exercise their superior knowledge with some care. Failure to provide duty and care is viewed as very serious. ·· Validates and maintains the accuracy of the statements: This is the most important responsibility and goes to the heart of the modeler’s competency. ·· Discloses any information that has a substantial bearing on the statements: Keeping back information that can directly or indirectly affect the interpretation of the financial statement is a serious breach and not just for the modeler who produced the model. Anyone who is involved with providing financial statements has an obligation to disclose information that is material. ·· Provides comments, notes, and supplementary information that will help to make the financials more transparent. ·· Presents justification and evidence to back up and prove the information that is in the statements has substance. The implications of glossing over or eluding these responsibilities depend on how those who have been affected decide to proceed with matters. However, the implications can lead to an accusation of professional negligence. The effects of professional negligence will vary. At the very least, you will lose the ability to continue to build models commercially. At the worst, you will lose your living, and you may have to make repatriation and compensation to the damaged party, which could be a corporation or an organization that has lost several million dollars.

The Handbook of Financial Modeling

Linking inputs to financials A crucial part of the overall end model is how the modeler has aligned the financial statements to the inputs. In a well-designed model, the link between the outputs and the inputs is transparent, which means any adjustments to the inputs are observable in the results of the outputs. To achieve this transparency, the modeler should employ a consistent approach to building the inputs and the outputs and avoid placing anything that breaks that consistency in the model. The key to linking the inputs and outputs is to use a top-down approach and start with the outputs and work back to the inputs. By using this approach, we already know what the outputs template should be, and we can then design the inputs to fit into that template. In Figure 9-1, our output is an income statement.

Figure 9-1.  A sample income statement

The best approach to creating inputs is top-down, that is, starting with the outputs working to the inputs and then developing the calculations. In the income statement, each of the revenue items (income) and each of the costs (direct costs and expenses) will have a specific input section. The inputs have been put together working back from the outputs as in Figure 9-2.

193

194

Chapter 9 | The Implications of Accounting Rules for Modelers

Figure 9-2.  This shows parts of the inputs to financial statements

By using the outputs to create the inputs, it becomes a matter of intuition and investigation to break down all the aspects of the output. For instance, for the sales revenue, you could simply have an input called sales revenue and input the total revenue per annum. However, you need to have flexibility; therefore, it is best to split the detail of the revenue into sales price × sales units. That gives you flexibility about whether the price or the number of units derives the sales revenue. In column A of Figure 9-2, reference codes have been included. These originate in the inputs, and they are also used in the assumption register and to a lesser extent in the financial statements themselves. By employing a reference system such as this, the assumptions and the inputs can be tracked, in effect giving an audit trail. This referencing does mean the modeler has to spend a considerable time documenting, but it is well worth it, particularly when the model goes into testing. Additionally, it helps the modeler to keep abreast of how each part of the model is functioning. The next step is to create the calculations, which should be based upon the information in the inputs as in Figure 9-3.

The Handbook of Financial Modeling

Figure 9-3.  The inputs appear at the top with the calculations below them

The calculations are linked to the inputs, and you will notice in Figure 9-3 at the top of the worksheet that all the inputs were brought in by simply creating a link. This may seem odd as I am duplicating the work that is already in the inputs, but it is to make sure that all the calculations that follow have a formula coming from the same worksheet, as in Figure 9-4.

195

196

Chapter 9 | The Implications of Accounting Rules for Modelers

Figure 9-4.  The calculations are generated in the workings

What this means is that when trying to track a particular item in the financial statements, you can locate that item in the calculations and then also analyze how the formula works—all within one worksheet. In Figure  9-5, all the references are shown on this income statement, which means anyone looking at this statement would be able to track the information. The use of these references also allows you to assess quickly how to remedy any errors. You will be able to either correct the formula in the calculations or look back at the inputs worksheet and alter the input.

The Handbook of Financial Modeling

Figure 9-5.  The linked income statement to inputs

Once the calculations have been created, it is then a matter of linking the relevant items in the financial statement back to the calculations. Thus, the statement is linked to the calculations, and the calculations are linked to the inputs. This may take some getting used, going through such a process, but a process it is for very good reasons. If the statements in the model are consistently following this linking, then any time there is a problem with statements; the process is always going to be the same. You will be able to check through the references and links. In Figure 9-5, take a look at column A, and you will see “Input ref:”. This is a reference column where, row by row, a code is supplied that references the input in the input worksheet. By creating this type of reference, it is then possible for whoever is using the model to track the source of the information. I have also added a Notes & Comments section, which while not necessary is a good accompaniment to the financial statement. These notes are eventually linked to the assumption register, and a lookup is created that will use the input reference number to locate the comments that have been used in the assumption register.

197

198

Chapter 9 | The Implications of Accounting Rules for Modelers

 nderstanding when to use U financial statements The financial statements are not purely for accountants. In fact, while accountants are always interested in these statements, the main beneficiaries of the financial statements in the model are those who want to gain a better understanding of where the project or organization has been or is going. This group of people will likely include the following: ·· Project owner ·· Business owner ·· Stakeholders ·· Investors ·· Lenders ·· Clients or customers ·· Bid tenderer ·· Public at large The question then becomes who should view which statement when. In a nutshell, which statements are the right ones to use and in which situations? Surprisingly, the answer is fairly simple. As the modeler, you should always be prepared to have available the three core statements, the income statement, the cash flow statement, and the balance sheet, even if these have not been asked for by the sponsor. These three statements combined are the basis for interpreting financial performance and make up the foundation behind so many other financial metrics and financial ratios. How would a modeler know which capital-budgeting metrics (net present value, payback, internal rate of return, or weighted average cost of capital), or which financial ratios, should be used? My advice is that you tread carefully when looking at which metrics or ratios to use because they all tell their own story. They also are very much dependent on what message you really want to put forward. If you are in any doubt as to which metrics to present, then bear in mind that these are the messages you should be trying to give in the outputs: ·· When is the payback of the project or investment going to occur? ·· What type of return would the investor get for putting funds into the project?

The Handbook of Financial Modeling ·· When will the project begin to break even? In other words, when will it will start to look after itself through generated revenues and will no longer require any investment? Again, this break-even point does not require a statement, but the modeler should be prepared to communicate when the break-even point will be achieved. To conclude, when determining how to use the financial statements, you should always use the three core statements and be clear on the payback period and, equally important, the break-even point. With any other financial statements, metrics and ratios will be on an as-needed basis. Also, it’s a good point to refer to the project sponsor as to which additional metrics or statements (aside from the income statement, balance sheet, and cash flow) would be required. As I mentioned earlier, all these metrics and ratios give some financial story; it’s up to you to make sure you know what is required. The accuracy of the outputs—whether they are income statements, balance sheets, cash flows, or liquidity ratios—should always be a paramount concern for any financial modeler. Let me be clear about what is meant by accuracy: you are testing the ability of the information to give whoever is looking at it as good an indication of reality as one can possibly get. When looking at historical data, expect the data to be a complete reflection of what has happened in the past.

199

CHAPTER

10 Modeling Scenarios Explored In this chapter, I want to take you through some specific examples of financial modeling situations. The examples can be seen as scenarios based on what has really happened when engaging with clients and building a financial model. I have mentioned before that one of the complexities in financial modeling is that no two models are ever the same, because no two real-world situations are exactly the same. That said, although the models will not be exactly the same, often there are some modeling situations (scenarios) that you will notice occurring frequently no matter what type of model you are asked to build. These are called standard modeling mechanisms. Financial modelers will all have their own methods on representing these standard mechanisms using their own preferred codes, formulas, and structures, but in the end, the result will always be the same. The sections that now follow will be modeling situations (scenarios) where I will take you through a standard mechanism and how best to tackle it. I will only be showing the scenarios which most commonly occur when building financial models. © Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6_10

202

Chapter 10 | Modeling Scenarios Explored I would like to challenge you to look at each scenario and have some thought as to how you would create your own mechanism and what you would do differently or do the same. You should keep in mind that all financial modelers have their own methods they like use, so best that you start to explore what your methods could look like.

The importance of the start dates Something all modelers know and understand about building models is that every modeling engagement bar must have a start date. Even if your client does not mention anything about timelines and dates, always make sure you build your models to work with dates, which can then move a timeline. Humans are time-driven creatures; everything we do can be related to a time measurement. Thus, financial models, being interpretations of activities in the real world, will always need to have a time driver. A model with no dates or ability to move timelines is not worth its salt, remember that. In Figure 10-1, we have a model with a timeline of 10 years. This means that the model can actively produce results if the start and end dates fall with a 10-year period.

Figure 10-1.  The timeline for the model can be controlled by giving users the option to control the start dates

The Handbook of Financial Modeling We give the user control of that timeline by letting them input the Contract Start Date in row 103 and also the No. of Months to cost (Contract duration) in row 101. You will notice in row 100 there is an input for No. of Months precontract. This is a useful trick to have in the timeline. What it does is capture the period (in months) that could occur before the model is active (contract start date to contract end date). On occasion, a user may need to reflect costs and revenues that impact the model project but occur before the project has commenced. Therefore, having a precontract period will solve this issue, should it occur. You may notice in Figure 10-1 the header in row 1 is actually glowing red, even though the error check in column D is TRUE.  We have discussed the importance of error checks in model, and this is an example of a useful error check. The worksheet is glowing red because somewhere in the model, there is an error caused because we do not have a start date. The check is red, which means it’s a critical error and the model outputs cannot be trusted. In Figure 10-2, if we take a quick look at the financial dashboard, which is an output, we can see that due to having no start date nor any contract duration (in Figure 10-1), all our money metrics for Total Price, Total Cost, Blended Margin, Cost of Money, and Residual Value are all meaningless because we have no idea of the time period and when these numbers occur.

Figure 10-2.  The financials do not have a timeline and therefore it’s difficult to discern which dates they relate to

Once we input the start date, and contract duration period in Figure 10-3, the model can calculate the contract end date which is Contract start date + no. of months of costs + no. of months precontract = contract end date

Figure 10-3.  The contract start date and no. of months to cost with precontract period have been supplied

203

204

Chapter 10 | Modeling Scenarios Explored By providing the dates and duration months, we can now see in Figure 10-4 that our timeline worksheet has updated with the dates. We can see from the timeline the date is starting in July 2020, even though our start date was for September 2020. You may recall the mention of the precontract period. So, if you look in Figure 10-3 row 100, you can see three months have been input. Therefore, our model needs to start from Contract start date – no. of months precontract = model start date October 2020 – 3 months = July 2020 The critical parts of the timeline are ·· The start date ·· The timeline with precontract months (row 29) ·· The company year These elements are used to define the period in which all the metrics of the model will be presented.

Figure 10-4.  The timelines update with start date which will then give a timescale control to the model

Now that the timeline has updated, we can be certain outputs will be synchronized with the details we input in Figure 10-3. When we take a look again at the financial dashboard in Figure 10-5, notice the change in the dates and months in column E. Now when we look at the numbers in column I, there is more context because we can, for instance, see that the total cost of 28 million is for a period between October 2020 and September 2024. We could then make a comparison to historical costs and check on variances by using column K (previous).

The Handbook of Financial Modeling

Figure 10-5.  The dates and months are now synchronized with the timeline

We should be able to clearly see now that having dates and duration inputs in a model with a standard mechanism (the timeline) to use the inputs to clarify the outputs is critical. When you next look at a financial model, just see if you can locate the use of dates to drive a timeline and, if so, how has the modeler who built the model achieved the mechanism. For completeness and because we are going to see more of the financial dashboard, Figure 10-6 shows the full scale of the output.

Figure 10-6.  The full financial dashboard

Reflecting real or nominal costs When building a financial model that will show movements in costs or revenues over a period of time more than one year, you should consider whether to include a mechanism to reflect either real values or nominal values or both.

205

206

Chapter 10 | Modeling Scenarios Explored So firstly, let me give you a brief explanation to the terminology or real and nominal in relation to finance and financial modeling. Real values are those that have had an adjustment made to them to take into account inflation movements. Nominal values represent money values as of the time of modeling or when the services or produce were made. Thus, nominal values should always state the date or time when they were stamped. At this stage, you could be wondering why even have nominal values as they don’t reflect the today’s values? That would be a valid response, but nominal values do have their usefulness. For instance, if we can make a fair and accurate comparison of cost to deliver a service or product, we actually don’t want the effect of inflation to cloud the comparison, and therefore would need to use nominal costs to get a real idea of the differences. With this in mind, for financial models, you really should make sure your models have the ability to reflect both real and nominal values even if these have not been stipulated in the requirements. In Figure  10-7, we have a table in our model inputs where we can input inflation. Generally, modeling the whole concept of building inflation into models is called indexation. So, we would say the model has or does not have indexation built in.

Figure 10-7.  The inflation can be represented in the customized indexation table

The Handbook of Financial Modeling There are some important factors to have in any indexation mechanism for a financial model: ·· Dates: The indexation table should be in concentric years, even if you have built the model from the lowest measurable timeline which is likely to be most. The reason is that although inflation does occur in smaller time period like months, economically track inflation on an annual basis. ·· Index rates: You should make sure all the appropriate and possible index rates are represented in the table. You will know when you see an index for inflation because it is always quoted as percentage (i.e., 3% per  annum) per year. There are several different indices with their own rates with most of them being specific to certain types of products, services, or industry. The most common and widely used indices in CPI (consumer price index) and RPI (retail price index). If the model you are building is based on a specific industry or there are some significant cost drivers such as cost of labor, you will need to create an indexation table that can accommodate several indices. ·· The mark month: Although not so important, you may want to get the indexation mechanism to apply inflation to values at a given point during the year. This will depend on prevailing standard economically where you are modeling and also in the industry you are modeling to. For instance, in the United States, inflation is generally applied in December, while in the United Kingdom, it’s applied in April. You will see in Figure  10-7 the indexation has the ability to use three points, years, various indices, and a mark month. We can use the financial dashboard to test the effects of the indices in the indexation on the total cost and total price. As our indexation table in Figure 10-7 does not contain inputs for inflation rates from Year 1 to Year 10, the financial dashboard in Figure 10-8 has had the indexation toggle turned to off.

207

208

Chapter 10 | Modeling Scenarios Explored

Figure 10-8.  The financial dashboard has indexation turned off, irrespective of whether the index table is populated

From the Dashboard in Figure 10-8 the indexation is of the total price is 35.5 million. So, what happens if we toggle the indexation to turn it on as in Figure 10-9?

Figure 10-9.  The indexation has been switched on

Take a look at the total price in Figure 10-9. Even if the indexation is toggled to on, the value is still 35.5 million. What does this tell us? It could be two things, either the mechanism for applying inflation and therefore getting to real values is not working or we do not have any inflation rates input into the indexation table. So, let’s narrow it down and put into the indexation table various rates for RPI, CPI, and CEL and labor as shown in Figure 10-10.

Figure 10-10.  The indexation table has been populated with annual inflation rates in four indices

The Handbook of Financial Modeling The rates are input for four of the indices in Figure 10-10. There is something that I have not explained yet. It may occur to why do we need so many indices and why would they all have an effect on the total cost and total price in the financial dashboard. The answer is hidden in the inputs and is based on tagging. When we input date into the model, we will be tagging each piece of data with an inflation index. So, for instance, this model is an IT services pricing model, and when we put through and labor costs, we will place a Labor tag. When we put any costs, cost related to transport, or logistics, we will put a tag for CPI against those costs. So long our data has a tag next to it based on the same indices in the indexation table, we can be assured when we apply our inflation rates to each index the cost tagged will receive an inflation change. Now that we have our inflation rates, when we look at the financial dashboard and turn the inflation toggle, notice how the total costs have risen to 36.8 million in Figure 10-11.

Figure 10-11.  The indexation switch is on, and the indexation table is populated and therefore the total price and total cost have risen

The exact increase is 3.56% after including the inflation rates in the indexation table. The increase looks about right because with have CPI ranging between 2.5% and 3.25% and labor is constant 4%. The cost are weighted toward labour and balance of the costs whether they, but we can hazard a guess that they are more heavily weighted toward labor cost. So, an overall increase would need to be below 4% and somewhere about 3.25%, which it is. We have looked at two of the most common standard mechanisms that you should learn to adapt into the financials you develop. We will go on now and look at other standard mechanisms which are not as mandatory as the date and the indexation, but still you will need to be able to address them in most of your models.

209

210

Chapter 10 | Modeling Scenarios Explored

Dealing with discounts The term discounts is a catch-all for anything that takes down the final price and weakens revenue. It may seem that in an ideal business world, there would be no discounting, because surely revenue is king, and we don’t want to decrease it. The reality is discounting is a normal part of business and happens in just about every industry out there. There are several reasons why businesses discount; I am not able to cover them here, but to say most of the reasons are based around incentivization. I would suggest you equip yourself with an understanding of this very powerful incentivization tool as you will find the discounting mechanism to be a common requirement for most of your future models. In Figure  10-12, the financial dashboard in the model has the toggle for discount is turned off. Notice the total price is 38.89 million and the blended margin which is the difference between total price and total cost is 21.6%.

Figure 10-12.  The discount toggle has been turned off, so no discounts are activated within the model

The discount amounts are held in tables in the customer charges and revenue profiling sections of the model as in Figure 10-13.

The Handbook of Financial Modeling

Figure 10-13.  The customer charging is where all the profiles related to prices are kept

Figure 10-14.  There is no discount on overhead costs at the moment

We can see that in fact there are several types of costs available to offer discounts on. If you are dealing with complex data, be prepared to break down the data into types particularly when working with cost data. In this case we have several different types of costs, of which one is indirect costs (overhead). In Figure 10-14, the discount for overheads is blank. We can now provide a 5% discount to customers for overhead costs incurred as in Figure 10-15.

Figure 10-15.  The overheads will now have a 5% discount passed on to the customer

211

212

Chapter 10 | Modeling Scenarios Explored So before going forward, let’s just have a mental check about the effect of the discounts of the total price. If we are going to provide a price for an IT service to a customer (total price), we effectively take our costs to provide the service, which include overheads. We then could add a margin on top of cost, and we have a price to the customer: Total costs + Margin = Total Price If we then decide to give a discount to the customer, we must discount the total price. What this means for modeling is that if we implement the mechanism correctly, we should see the total price reduce when we apply a discount. This will be our check to make sure the discount mechanism is working. In Figure 10-16, the discount toggle is on and therefore applied (5%) now; notice that the price is now 38.87 million, as opposed to 38.89 million in Figure 10-12.

Figure 10-16.  The discount toggle is on, and the total price is the 5% on overhead

So, we know that the discount mechanism is working, although it does look strange that even though we input a 5% discount, the total price is showing a somewhat less than 1%. The reason for this is down to the cost profile of the data in the model. While we did place a 5% discount on overheads, these costs (overheads) are less than 6% of the overall cost type, so effectively we are discounting, 5% of 6% which is third of a percent (0.30%). So, the small change in total price is correct. Implementing a discount mechanism can be made as simple or complex as you want, but more importantly the model should have one. I have come across models where the client has decided later that they want to give discounts to their customers and need to understand the impact of such a strategy. Because the financial model doesn’t have the mechanism to discount, the client (user) decided to hard-code discounts into the price and consequently overwrote several critical formulas and codes, thus destroying the model’s integrity.

The Handbook of Financial Modeling

We need our margin In business, people talk about margin because that’s the precursor to profit. Without profit and good cash flow management, a business will not last and eventually fold. So, is margin the same as profit? This is a peculiar one, because the answer is both yes and no. Firstly, profit is the amount of surplus cash left over after all the costs of operating the business have been paid or covered to be paid. Profit is the amount of money that will eventually end up in the pocket of the owners of the business or will be used to reinvest into the business. Margin is the amount added to cost that is not directly attributable to that cost and is therefore more of a contingency. Therefore, margin can be seen as a part of costs. The ethos is that if you place margin on top of your costs to get to a selling price, when customers buy the good, you should then have made a surplus exactly the amount of the margin. Having a margin mechanism is very important, particularly in models where the eventual goal is to derive a selling price for goods or services. It also allows the model user to create “what-if”–type analysis, such that what if I increase the selling price, how much profit can I make? Having a margin in the model means the model user can forecast the revenue increases for price increases without manipulating the business operations and potentially increasing costs. Increase your margin, increase your profit; it’s that simple. In Figure 10-17, the financial dashboard toggle for margin is turned off, and therefore the total price is equal to the total cost and there is no blended margin.

Figure 10-17.  The margin is off, so there is no blended margin because total costs are the same as the price

To develop the margin mechanism, we need a table in the inputs that has a list of costs and the option to add a margin percentage against each cost type like in Figure 10-18.

213

214

Chapter 10 | Modeling Scenarios Explored

Figure 10-18.  The margin inputs table

You do not have to have a complex margin table as the one in Figure 10-18; all that is required are the service types or costs and a line to put a margin. In this model we also want to distinguish between general margin and margin based on operating costs. In some cases when building outsourcing financial models, being able to patrician margin into operating costs, general costs, fixed costs, and so forth is useful because the client may want to track where the source of the profit is coming from. In Figure  10-19 having input a margin against each of the services, the expectation will be to have a blended margin in financial dashboard that averages across the services and the margin areas.

The Handbook of Financial Modeling

Figure 10-19.  The margins have been input to the table

Notice now there is 25% general margin, but a 11% operating costs margin. In this model we have set a hierarchy which means all costs will have a 25% margin added to them of which 11% will be apportioned to operating costs. In addition, only after there is a clear 9% gap will the operating 115 be apportioned. We can see in Figure 10-20 that the margin toggle is now ON and the total price has increased from 27.7 million to 36.9 million. The increase is all due to the margin, which when blended is 25% of the costs, just as our inputs.

Figure 10-20.  The margin toggle is on, and there is an increase in total price and blended margin

You should endeavor to build your financial models always with a mechanism to compute margin. If the requirements do not state margin is needed, then the best way is to do as I have, and have margin but use the data validation list to toggle margin off and on. I have purposely not shown any of the coding or formula for any of the mechanisms but don’t worry too much at this stage. Most of the concepts we have covered in the book so far will be described in formula and coding in the next chapter (Chapter 11).

215

CHAPTER

11 Calculations for Financial Modelers So far in the previous chapters, we have looked into the structuring on financial models and working through best practice paradigms. In this chapter, we will focus primarily on the detail of creating and using formula. Excel contains a bewildering number of functions, and it’s nigh on impossible for anyone how to use each and every function. In fact, there is no point because what really matters is not how to use a function but when to use it. The focus in this chapter is about those functions and formulas that are typically most helpful to financial modeling and would be used for aspects of modeling. This chapter has a lot of details and at times is complex, but I would urge you to go through the whole chapter and get familiar with the formula. You can then always come back to it again and again in the future for reference. Before we head off into the calculations, this is probably the right time to clear up about financial modelers and Excel. There is a widely held perception that being a financial modeler is tantamount to being an Excel expert or guru. I cannot deny that financial modeling and Excel do go hand in hand and financial modelers are in general very good at using Excel.

© Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6_11

218

Chapter 11 | Calculations for Financial Modelers However, a financial modeler is not necessarily an Excel expert, nor is an Excel expert necessarily a financial modeler. The two fields are different in that Excel experts are just that they are masters of the Excel environment to the extent that they are able to code and develop applications through the Microsoft studio environment. Financial modelers are experts in converting real-world data and assumptions into visual and logical presentations and use Excel as a tool to achieve those goals. Albeit some modelers have a formidable array of skills and tricks in Excel; nonetheless, they are not Excel experts in their own right. Therefore, always make it clear to clients and anyone interested in your modeling services the distinctions between a modeler and an Excel expert because there are a lot of people who don’t get it, which can cause confusion when you are taken on for an engagement by a client.

The difference between functions and formulas I have taken it for granted that there is an understanding of what a function is as opposed to a formula. If so, please excuse me and let me explain. A function is a predefined code or word in Excel which was created by Microsoft developers to extend the capabilities of Excel calculations. Functions in Excel are typically donated with a word and with opening and closing brackets such as INDEX ( ). The brackets are there to tell us that we need to place certain information in between them in order for the function to work. Each function has a specific construction and not all functions are the same; therefore, you will need to actually learn the specific construction of the function you want to use; they are not always intuitive. A formula on the other hand is really a calculation statement that uses one or more joined functions. Just about every function in Excel is capable of being used with several other functions, the limitation is purely down to the vision, skill, and logical understanding of formula constructing of the modeler. It is well worth investing in a good book on Excel programming to get a thorough understanding of what each function in Excel does and how to build a formula. This book does not explore Excel in any depth and therefore should not be used as a learning Excel template. However, for the financial modeler, this chapter will be a valuable source for pretty much most of the functions and formulas you will need. Once you learn a particular method of creating a formula, you can then create your own tailored library of formulas which is how most modelers use Excel functions.

The Handbook of Financial Modeling

The base functions In this section I will take you through a series of Excel functions and their constructions which because of their wide usage in modeling should become second nature to use.

Worksheet headers and labels We have discussed previously how all worksheets in an Excel model should contain a header section at the top of the sheet with various descriptions relating to the model. Figure 11-1 shows the typical header information which includes the file name, the client name, the name of the model, and the worksheet name.

Figure 11-1.  The worksheet header contains various information about the model and worksheet

The headers are created by text functions to create a formula that identify the model file name.

Figure 11-2.  The formula for the file name

The text functions are described in more depth later in the chapter; however, we can take a look at the formula construction. The key to the formula is the CELL ( ) function. The CELL ( ) function can give information about the makeup of a single cell in the worksheet as can be seen in Figure 11-1b and is always useful for documenting and labeling worksheet.

219

220

Chapter 11 | Calculations for Financial Modelers

Figure 11-3.  The CELL( ) function gives information about the cell in focus

From the formula in Figure 11-2, notice the term Filename has been used. The CELL ( ) function is able to support 12 distinct pieces of information about a cell; however, the Filename item actually gives details about the physical location and name of the model (as in Figure 11-4). With a careful use of text functions, we can break up the details given by the file name to produce discrete labels.

Figure 11-4.  The Filename can only be used with the CELL( ) function and gives the location, the file name, and sheet name where the cell is located in the model =MID (CELL(“Filename", D11),Find("[",CELL("Filename",D11))+1,FIND("]", CELL("Filename",D11))-FIND("[",CELL("Filename",D11))-1).

This formula is taking the cell C11 and bringing up the location and file name. Excel always captures file name details within curly brackets [ ]; therefore, the formula is using the MID text function to show only those details in between the brackets. The result produced is the heading label in Figure 11-1.

The Handbook of Financial Modeling If you are thinking that it’s possible to also isolate the worksheet name from this same file name detail, then you are right. The formula in Figure 11-5 gives the worksheet name and is similar to the one in Figure 11-3 with two notable differences being the use of cell A1 this time and also use of a function LEN( ). The use of cell A1 is not important; we can use any cell in the current worksheet; it just so happened we used A1.

Figure 11-5.  The formula uses the CELL and Filename to isolate the worksheet name

The LEN( ) function is described later in the chapter, but I suggest you try to replicate the formulas in Figure  11-3 and 11-5 while experimenting with changing the worksheet names and file name noting how the formulas react. This is the best method of becoming familiar with using these CELL functions.

The SUM( ) function The SUM( ) is universally the most used Excel calculation function and possibly the simplest function to perform and learn. Despite its simplicity, the SUM( ) is an incredibly powerful function that is indispensable and forms the basis for other types of functions. Take a look at Figure 11-6.

Figure 11-6.  The total of the list of six numbers is calculated using the SUM( )

The syntax for the function in Figure 11-6 would be =SUM(D5:D10)

221

222

Chapter 11 | Calculations for Financial Modelers This function is simply saying, take everything between the cells D4 and D9 and add them up. The SUM( ) function is used whenever there is a requirement to summarize a set of data by making them into a total. For financial models, we use the SUM( ) function mostly in the workings (calculations) worksheet to aggregate the inputs, and we also use the function to make error checks. While the SUM( ) function is simple to use, it does have issues. The most common problem you will encounter is when there has been an error in the underlying data in Figure 11-7.

Figure 11-7.  The SUM( ) function cannot compute due to an error in the table data

The error which we see in Figure 11-7 can be quite a nuisance because if left unchecked, it will propagate through the model to every cell that has links with the cell. This type of error can stem from an input which has been entered incorrectly, for instance, the input calls for a number and the user has entered a text figure. The best way to avoid such issues is to make sure you users are given enough feedback when entering inputs such that they don’t enter the wrong type of data. However, having said that, you could anticipate user mistakes and create a formula that will still compute when there is an error such as Figure 11-8.

Figure 11-8.  There is an error in the underlying data, but the computation is still completed

The Handbook of Financial Modeling The formula required to produce a computation irrespective of an error in Figure 11-8 is =SUMIF(J3:J8,"N/A") You will see the SUM( ) function has been changed to a SUMIF( ). This function does much the same as the SUM( ) in that it aggregates the data between two cells but will also apply a condition. In this case we are saying, take all the data between cells J3 and J8, add them up, but ignore anything that is not applicable (N/A) and still produce a total. There is one caution to using the SUMIF( ) function to overcome errors; you still need to create error checks in the model to ascertain when a user is entering the incorrect data. You should only use the SUMIF( ) to overcome errors as temporary measure for testing the functionality in the model, but not as replacement for error checking.

SUBTOTAL(  ) One of the useful features in Excel is the ability to filter on the data. This is the ability to take subsets of your data and applying a filtration to show only those items required while hiding all other data. A problem can occur when filtering on data, if you require to aggregate just the filtered data. The SUM( ) function will always give you an aggregate of the data between two cells, irrespective of whether that data is filtered. So, if you are relying on a dynamically moving aggregate based on filters, the SUM( ) function will not work. Fortunately, there is another function which acts much like the SUM( ) but will react to filtering. In Figure 11-9, the same data used in Figure 11-8 has had a filter applied such that some of their data is hidden.

Figure 11-9.  A filter has been applied hiding the two data items using a filter

223

224

Chapter 11 | Calculations for Financial Modelers You will see in Figure 11-9 that the aggregated amount has also changed and reflect just the items that are unfiltered. The formula for this is =SUBTOTAL(9,M3:M8) The SUBTOTAL( ) is a function which responds to any breaks and filters in the data. This is a very versatile and often overlooked function which is well worth learning to use. The function can do a lot more than aggregate; it can be used to count, perform averages, and many more simply by changing the number at the start (in our case we use 9, but if we used 2, this would count the items of data). The formula is saying, take all items between cells M3 and M8, and aggregate them because we have used number 9.COUNT( ) Aggregating data is one thing, but often you will need to count the number of items of data. Typically, the COUNT function is used in models when checking the integrity of the data particularly if it has moved or to compare changes in two or more data sets. As can be seen in Figure 11-10, the functions count the number of items between two cells.

Figure 11-10.  The COUNT( ) function does not aggregate; it counts the number of items

The function syntax is very similar to the SUM( ), except this time we use COUNT. The syntax in Figure 11-10 is COUNT(D13:D18) When using the COUNT( ) function, it’s important to understand that the counting is limited to only integers. That is numbers; the function will not work if you are counting text. The problem is you don’t get any warning of the issue; the function simply returns zero (Figure  11-11). I have come across models where there has been a mix of texts and numbers and the COUNT( ) results have been used erroneously.

The Handbook of Financial Modeling

Figure 11-11.  The COUNT( ) is required to count text and returns zero

The best way to avoid issues of data type is to bypass the COUNT( ) altogether and use the COUNTA( ) function as in Figure 11-12.

Figure 11-12.  The COUNTA( ) function will also count text

While we are looking at the counting, there is another counting function that has its place in modeling. The COUNTIF( ) function is much like it sounds. This function counts the items based on a condition that you set. Figure 11-12 has a set of data which are being counted based on the condition of everything over 8 only. The syntax for this formula is COUNTIF(J13:J18,">8") SUMPRODUCT( )

225

226

Chapter 11 | Calculations for Financial Modelers

Figure 11-13.  The COUNTIF( ) function must have a condition that is met to count

There is one base function which is not used nearly enough in modeling but is very useful as shown in Figure 11-14. The SUMPRODUCT( ) is an aggregation function similar to the SUM( ) but also has some added abilities.

Figure 11-14.  SUMPRODUCT is an agregate of Column D & E

The function compares the two data arrays (array means a list of data), and as long as they matched in size, it will multiply each item in one array to the other and then produces the aggregate of the combined arrays. If you are unclear, take a look at Figure 11-14. There are staff numbers and salaries. For example, in Row 22, there are 5 Staff who have a salary of $1,200.23 (per month). The total of that salary band is $6,001.15. So instead of creating a calculation for each salary band for salary x staff, all we need to do is create a SUMPRODUCT( ) function in row 28 as an aggregate. We have satisfied the conditions because we have two arrays (staff and $) that are matched.

The Handbook of Financial Modeling The syntax for SUMPRODUCT( ) in our example is =SUMPRODUCT(D22:D27,E22:E27) You may notice in Figure 11-14 that one salary array has been given a range name called departments. However, irrespective of how we represent the arrays, the function will calculate so long as the arrays match in length. If you encounter a problem with the SUMPRODUCT, it’s likely that either your arrays do not match in length or you have a data type that cannot be aggregated such as text.

Lookups and math In this section I want to look at function reference information from a cell or range and then give a result of what they have found. I also want to introduce a few math type functions that are useful to have in your armory.

INT(  ) The INT( ) function will take a number and will pull out just the integer so that any calculation therefore after is dealing with the integer only, and no decimals as in Figure 11-15. If you are familiar with rounding in numbers, you could argue why not just round the number in which case it could be rounded up or down. Well the INT( ) function is strictly not a rounding. It actually truncates the number and discards any decimals. There are a number of real uses for the INT( ) function. When you require a definite result and do not want the effects of rounding, then this is when you use the INT( ) function. When building a model and working with time periods, often we need to force our time periods to present a single unit for instance: 6 weeks = I month 7 weeks = 1 month 8 weeks = 2 months 9 weeks = 2 months

227

228

Chapter 11 | Calculations for Financial Modelers

Figure 11-15.  The INT( ) function has been applied against the $ values.

You won’t need to use the INT( ) function often, but I can assure you there will times when you will need it. This is not a function you should discard easily.

MOD(  ) The MOD( ) function acts like the numerator and divisor in math. For a quick recap when dealing with fractions, the number on the top is the numerator which is divided by the number on the bottom which is the divisor. The function then does one more thing, it produces the remainder. So, for example, if we have 8/3 = 2 remainder 2. This 3 goes into 8 twice, with 2 remaining. So, let’s look at Figure 11-16 to see how the formula is written. The function is applied against each of the values giving a result that is rounded down.

Figure 11-16.  The MOD( ) function applied to staff and pens shows how many can be divided equally between each staff member.

The Handbook of Financial Modeling I imagine it’s not immediately clear when and how the MOD( ) function could be used in a model to you right here. This function like the INT( ) is not frequently used, but there will be instances when the function can provide real power to your models. The MOD( ) function is particularly useful when you have a set of changing numbers that are dealing with a constant. For instance, you may have dates that are changing, but we know that seven days = one week. In this case you might want to force the number of days (numerator) and against a week (divisor) to set how many days remain. This could then be used as a trigger to set off given actions against certain time periods. One of the many uses of the MOD( ) function is when dealing with waterfalltype scenarios and gates where various options are available after a given number of occurrences. Another area where I use MOD( ) function is when I need the model to react differently based on an odd or even number.

INDEX(  ) There are some functions that are absolutely unavoidable. One such example is the INDEX( ) function. It’s such a useful function that when used with other lookup functions really gives an added power to models. I am always amazed that this function is not used more often, but there seems to a real fear of so many modelers on how to use it. So, let’s get you started on using this fantastic function without any hang-ups. The purpose of the INDEX( ) function is to give the position of specified item with an array of data. Here is an analogy to get you thinking in the index manner. Imagine there is a direct road that runs between your home and your workplace. The total distance of that road is 15 miles. There are several people who use that same road to get to the same place as you, who also live somewhere on the route. One such person is John, and he drives a red car. Another is Susan and she drives a blue car. Imagine then one day you have a morning meeting with both John and Susan, but they are both late, so you want to know where they are, so you ascertain when they will be available for the meeting. We know they are likely to be on the road to work, which we know is 15 miles long from end to end. If we could ask a locator to tell us at which mile point they are on that road, we may get a return something like this: John = 8.5 miles from the start Susan = 12.2 miles from the start

229

230

Chapter 11 | Calculations for Financial Modelers Because you know the workplace is at the 15-mile point, you know exactly where both John and Susan are and can now make a reasonable estimate of when they will be available for the meeting. Thing of the INDEX( ) function being just as described, the road is the array of data, and Susan and John are the specified items (people). The function will return where on that array they are which we can see in Figure 11-17.

Figure 11-17.  The INDEX( ) function uses an array, with the row number and column number to get the position of a specified data

The syntax in our example is INDEX(D5:E11,I6,I7) We can examine the example and formula further: Step 1: The part of the function is to put down the complete coverage of the data being used (the array). In this case it’s everything from D5 to E11. Step 2: Next, we need to in which row of the array our data is in, and then in which column. In this case we have identified the input for row number is in cell I6 (3) and the input for column number is in cell I7 (2). Step 3: The data we want is in the array D5–E11, its three cells down beginning from D5, which means it’s in row 7 (remember the starting row is inclusive and an array includes titles). Step 4: Next, the data is in columns from our start position which is D5 again. So, it’s in column E. Step 5: We now know that our data must be in cell E7, which as our result shows in Figure 11-17 is $800.43. Notice the use of inputs rather than hard-coding the numbers directly into the formula. It’s important that no matter how time-consuming it may be, you should use inputs and never hard-code for the reasons we stated in the “Best Practice” chapter.

The Handbook of Financial Modeling

MATCH(  ) The MATCH function is used to search for a specified item of data with range and gives the result of the location within that range. Although this function is not much use simply on its own, its power comes when combined with other lookup functions in particular the INDEX( ). In Figure 11-18, we can see the make and syntax for the function and that the result.

Figure 11-18.  The Match( ) function searches for a specific data in a range returning its location within that range

Notice in the syntax in Figure 11-18 the zero on the end. The function needs to know the matching type, such that how close do you want it to match. A Zero (TRUE) is saying find the exact match to Mar, if you cannot find it then return and referential error. If we were use a 1, then we would be saying, find the closest match to Mar. If there wasn’t an exact match, the function would nonetheless return something. Be careful if you use the 1 (FALSE) for match type as the results are unpredictable.

INDEX( ) and MATCH( ) combined The ability to create customer lookups is one of the most attractive features in Excel. We covered in the two seconds prior the INDEX( ) and the MATCH( ) functions. Now when we combine these two functions, we can take the lookups feature to another level. Using this combination, we can identify an item of data and then for when that item appears in an array. In Figure 11-19, we can see how the syntax for the INDEX( ) and MATCH is created.

231

232

Chapter 11 | Calculations for Financial Modelers

Figure 11-19.  Using the INDEX( ) and MATCH( ) provides a flexible lookup alternative to VLOOKUP( )

Let’s look further into our example in Figure 11-19. The syntax is =INDEX(D25:F32,MATCH(I26,E25:E32,0),I28) Step 1: Firstly, we define the data range which is from D25 to F32 and includes the headers. Step 2: Having established the whole data range, we need to provide what we want to find which is the input in cell I26 (Dept4). Step 3: Overall, we need to let our index know in which row our search days will be. We use the MATCH( ) function to identify our data Dept4. If you recall the function returns the row location where Dept 4 occurs in column E. Step 4: We want to let the matching know the type of match which with a zero we want an absolute match. Step 5: Lastly, we need the index to know which column we want returns after the match which is input I28 (3). So, what we have actually done is define the array using the INDEX( ) function (D25:F32), and then we have used the MATCH( ) function to set the row where the Data lookup I26 (dept4) and the Column I28 (3) are located. The result comes from row 29, column F or F29 which is 460. If you are familiar with the VLOOKUP function in Excel, you may notice similarities between using the INDEX( ) and MATCH( ). In which case why go to all the bother of creating a custom formula when they are already a function available that does the same job. The question is: does doing the VLOOKUP do the same job? In some ways it does, but unfortunately for building financial models, the VLOOKUP function has two very important flaws, which must be avoided.

The Handbook of Financial Modeling The first problem is the VLOOKUP function is static. You must specify how columns from the start point you need to look up from. This means if a user inadvertently deletes or inserts a column in the data range, the VLOOKUP( ) will give the wrong results and is basically redundant. You might think there is little chance of that happening; think again. Using VLOOKUPS is a serious risk. The other is that the VLOOKUP is a volatile function. This means once it’s created, Excel will continue to process and run the function hundreds of times a second. Imagine you have thousands of VLOOKUP( ) in you model. The computer processing power required is increased and will not just slow down the operation of the model; it can cripple it. Most of the models I have been asked to rebuild have come about because they were built on a heavy base of VLOOKUP( ). As a guide when you look at a financial model, check to see how many VLOOKUP( ) functions are being used. If you find any, then it’s likely the model you are looking at has been built very purely or by someone who is not a financial modeler.INDIRECT( ) The INDIRECT( ) gives the result of reference from a cell. The best way to think of it is that it tells you where and what is in a cell given by another cell. Figure 11-20 shows the syntax which is quite simple.

Figure 11-20.  The INDIRECT( ) function tells us that cell D41 is pointing to cell E41

In Figure 11-20, the function is looking at Cell D41 and checks to see if there is a reference to another cell. In this case there is a reference to cell E41, which is Jan. The INDIRECT( ) function is another which when used with other functions becomes incredibly powerful. Its use is that it is dynamic and if used well can change the parameters of a model simply by altering one cell or a range of cells. In Figure 11-21, the function has been combined with a SUM( ) function to give the ability to provide a choice between two calculations. Because the data in E45 drop-down list points range names for Competitor 1 or Competitor 2, we can simply alter the result of calculation just by changing the data in E41.

233

234

Chapter 11 | Calculations for Financial Modelers The INDIRECT( ) function is almost always used on the inputs, and as powerful as it is, you should also be aware that you document precisely how it’s being used through the model because it does make auditing very tricky.

Figure 11-21.  The combination of functions means two sets of data can be chosen just by using the drop-down in E45

IF( ) The IF( ) is a logical function that is used to test for one or more conditions and then to proceed with a given set of instructions. This function is incredibly useful and should without doubt be one of the tools of any modeler. In Figure 11-22, we can see the construction of the function.

Figure 11-22.  The IF( ) function is used to test condition and take action

In Figure 11-22, the syntax is used to test if the data in E6 is greater than 480, and if so, it will result a message stating passed; however, if the data is below 480, it will pass a message failed.

The Handbook of Financial Modeling The IF( ) statement is very useful when testing if conditions in the inputs have been met or a specific parameter has been reached. You will find this indispensable when creating models. The function can be expanded by including the ability to test two conditions combined to see if both have been met by using the AND( ) and the OR( ) functions as in Figure 11-23.

Figure 11-23.  The function test for two conditions before taking an action

In the example the formula is testing to see if production in O5 is greater than 480 and the month is Feb. If it is, then the result will be a pass, but if not, then the condition has failed. This IF( ) function can also be used with the OR( ) function in much the same way as in Figure 11-24

Figure 11-24.  The OR( ) function is used to text if one or other condition has been met

The OR( ) function rather than text for two conditions being met seeks to find if one of the two conditions exists. SUMIF( ) We looked at the SUMIF( ) function in an earlier section, but we need to look at its wider use. The function is very common in financial models, and you will find it virtually impossible to build a model without using it.

235

236

Chapter 11 | Calculations for Financial Modelers

Figure 11-26.  The SUMIF can be used on a set of data to aggregate the items that meet a given condition

The SUMIF is literally the SUM function with conditions. Unlike the IF( ) function which will look at one item, the SUMIF( ) can be used in a range of data to aggregate that data based on a given condition. From the example the first step is to define the data which we want to test for a condition which in our case is in column D with months. The formula then uses a criterion for the condition in Cell I13 which is Mar, and then we define the array that will be aggregated which is in F13–F18. We can see that there are two items which satisfy the Mar month criteria in E15 and E17; these are then aggregated giving a result of 909. In the previous versions of Excel, it was only possible to test one condition using SUMIF( ), but it became apparent Microsoft that modelers would sometimes need to test more than one condition. Fortunately, today Excel has an additional function in SUMIFS( ) which is capable of testing several conditions as in Figure 11-26.

Figure 11-27.  The SUMIFS( ) is not limited to one condition and can test for several

The Handbook of Financial Modeling In this example just like the SUMIF( ), first define the range that will be aggregated which is in column F between F24 and F30. Next, define the range where the first condition will be tested which is E24–E30 and then point the formula to the criteria we want to test for in I24 (Dept2). For the second condition, we can then define the range with the second condition in column E E24–E30 (departments) and point to the criteria we want to test for cell I26 (Feb). The result will be an aggregate of those cells that have both Dept and Production meeting the criteria Dept 2 and Feb which in this case is 987. The SUMIFS( ) function has pretty much made the SUMIF redundant because of its greater ability to take on more than one condition. Ideally you should make sure you are comfortable with both SUMIF( ) and SUMIFS although you will almost certainly use the latter.

Other useful functions In this section I will run through other functions that would be helpful to build a familiarity with, albeit they may not always be used.

IFERROR(  ) The IFERROR( ) function does not perform any calculations of lookups but is a wraparound which you place over an existing formula to catch an error that could occur and perform a specific action when such an error occurs. In Figure 11-28, the function has been used to catch errors in a SUM function.

Figure 11-28.  Using the IFERROR( ) function to trap errors

The syntax for the error trap in Figure 11-28 is looking at the SUM( ) function in O37–O42, and because an error has occurred, it will then perform a SUMIF( ) with a condition to aggregate even with an N/A error.

237

238

Chapter 11 | Calculations for Financial Modelers This is a very typical use of the IFERROR function. One thing to note is to not judicially use this function because often you may need to understand why and where an error has occurred. One of the problems with the IFERROR( ) is by circumventing the error; it can lead users to a false sense of believing everything is okay with the model, when in fact there are errors that need to be investigated. You should always provide some documentation alerting the user that an error trap is being used and also create an error checking on the data to isolate the problem cell.

EOMONTH(  ) The EOMONTH( ) is a simple function but with an immense usability. As in Figure 11-29, the start date is an input in E16; the number of months between the start dates is also an input in E17. The result of formula in E18 is the start date + 5 Months = End Date (to the end of the month).

Figure 11-28.  The EOMONTH( ) calculates the end of the months from a given date and periods

The EOMONTH( ) will always result in the end of the month, and for this reason it’s a great function to use on financial statements or any data that is calculated for the end of the month. For instance, I use EOMONTH( ) when creating timelines or when working with data that has to calculate interest earned or interest payable, amortization, depreciation, or inflation because in the real world, we use the end of month for calculations.IRR( ) IRR stands for internal rate of return and is used in capital investment to determine the profitability of an investment. The IRR always stated a metric which a company will set as a point at which they will invest or not invest. The use of the function is relatively simple as in Figure 11-29.

The Handbook of Financial Modeling

Figure 11-29.  The IRR( ) function gives a single metric in %

The formula requires an array of numbers which pertain to the annual cash flows arising once a capital investment has been made. The first cash flow is always Year 0, as that is when the investment is made, and subsequent years follow with Year 1 to whenever the investment is deemed to have outlasted its useful life. In our example the cash flows are between E2 and E6, and we need to then agree on interest rate guess that we believe we could achieve with the same amount elsewhere. In this case, it is 5%. Notice the deliberate mistake, in that the interest rate should be an input but instead I have hardcoded the number, which make this formula static. The result is given in H7 which at 15% may be a trigger to go ahead with the investment or not. Much depends on which level of IRR the company has set as target to enter into an investment. The IRR( ) is one of several functions in Excel that are specific to a particular scenario and cannot be used on generalpurpose data. The trick to building the formula is to organize the data simply much like the example to make it easy to calculate.NPV( ) NPV is the net present value used to ascertain the current value of future cash flows from a capital investment. It basically tells you how much your future money would be worth in today’s money. I won’t expand on the relatively merits or problems using NPV, but to say with all capital investment metrics, they should be used in combinations rather than as discrete metrics. In Figure 11-30, the cash flows coming from a capital investment are in the array between E10 and E14 including the actual investment in Year 0.

239

240

Chapter 11 | Calculations for Financial Modelers

Figure 11-30.  The NPV( ) is based on calculating cash flows with a required return rate

You will notice in Figure 11-30 how the initial investment in Year 0 is shown as negative, that is money is going out of the company, and the cash flow is positive because it’s money coming into the company. The formula in our example first takes the required rate of return for interest on the investment in H10 and then sets the array for cash flow but only from Year 1 E11–E14. The formula is peculiar because actually NPV should be calculated from the initial investment (Year 0) but somehow Microsoft got this wrong, and if you try and set your array from Year 0, you will get an incorrect NPV. To compensate for this problem, we need to reflect the initial investment outside of the array by adding it back which is why our example shows +E10. The result in H15 is the NPV which when positive is always a good sign. Let me just reiterate that NPV is a very critical metric which if you put into financial model will almost definitely be used to make critical investment decisions. You cannot afford to make a mistake because of calculating error, so make sure you always remember the quirk in NPV( ) function.

Using best practice calculations Almost all of Excel’s functions are ready for use by anyone, and they all have their own advantages and disadvantages. What makes them particularly effective is how they are applied and used. With that in mind, in this section, I will take you through a series of calculations (a situation that requires a calculation to be performed) and offer a solution of how to perform these calculations efficiently and follow best practice modeling.

The Handbook of Financial Modeling

Whole range calculations The whole range calculation is an efficient calculation method with several benefits, particularly on large models. If you can invest some time setting up a range, I can assure it’s well worth the effort. It involves giving a name to a series or a range of cells, and once that range has been named, it can then be used simply by referring to the name in the formula. In Figures  11-31 and 11-32, take a look at the inputs at the top and the calculations below the inputs. At the top of the calculations, the input links have been brought into the calculations; however, instead of linking each cell across the eight years individually, I have referenced the name “Inp_Income” (input income). By using this name, I now only need to use the same name across the income row, and the link will give me the corresponding income amount. This method does away with having potential pointing areas because the modeler just needs to know the range name of each input row, which I have added in column L as a reference.

Figure 11-31.  The cell in E28 has been linked to the range name Inp_Income

241

242

Chapter 11 | Calculations for Financial Modelers

Figure 11-32.  In this financial model, the whole range of cells from E28 to K28 references a single rage name called Inp_Income

Let’s take a look now at how to create a whole range name. Begin first by highlighting the whole range that will be named, and make sure the starting column and the ending columns will remain consistent throughout the model. In Figure  11-33, columns D and K are the starting and ending columns, respectively.

Figure 11-33.  The first step is to highlight the full range that will be named

The Handbook of Financial Modeling The range can then be named using the name box, which is located in the upper left of the worksheet just above the A and B column headings. Give the range an appropriate name (see Figure 11-34). By creating these range names, you can make calculations that are based on names. For example, to determine the gross income, you could write the following calculation: Input_Income *( 1+Inputs_SalesTax)

Figure 11-34.  The whole range has been named “Inp_Income”

By using the whole range names, you can start to make calculations that when viewed become more meaningful. However, always make sure the columns are consistent, as any calculations that are made on inconsistent columns will mean that the results are unreliable (see Figure 11-35).

Figure 11-35.  The columns between the inputs and calculations are misaligned, and therefore the calculations are unreliable

243

244

Chapter 11 | Calculations for Financial Modelers

Calculating time periods Making calculations that are based on time periods and time intervals can be very frustrating because of the conflict between what is pleasing and intuitive to the eye and what is practical and sensible modeling. To explain, see Figure  11-36. This is an all-too-typical situation. The modeler needs to produce some outputs, which are likely to be in a standard format based upon the client’s requirements. The results do not look very appealing.

Figure 11-36.  The outputs are reported in quarters and years

In this model, the outputs are reporting in quarters and then totaled into years. Although there may appear to be nothing particularly harmful about such an output, it couldn’t be further from the truth. This output is a disaster, and it really is the antithesis for any financial modeler. There is a lack of consistency across the columns as some are showing quarters and others are showing years; they should all have the same timescale. In each row, there are four calculations for the quarters and then a different calculation on the total. One of the problems with this output is if you needed to reference it from another worksheet, you would be required to always check which cells are being used because some are in quarters and others are in years. The importance for modeling is to break this type into an output with quarters and an output with annual numbers in your calculations. By creating two separate calculations, you can then create outputs that give both quarterly and yearly numbers without breaking best practice consistency. Different ways are available; one of the solutions is to use a tool called pivot tables. These pivot tables are very popular in financial circles, but there is just no room for them in financial modeling, such that I am not going to discuss them. In short, they are cumbersome and present major problems if you want to create calculation links from them. A better way is to use a calculation mask. A mask is a simple function that is created specifically to signal whether certain cells are included or excluded. Figure 11-37 is an example of a mask that has been created to accept time period quarters but nothing else.

The Handbook of Financial Modeling

Figure 11-37.  In this model, the calculation mask is being used on the time periods

You can see that the quarters are simply labeled 1, 2, 3, and 4. It’s generally easier to perform calculations on labels if they are numbers and not text. I have named the table with the time periods “TableHeadings,” which makes it simpler for referencing. The formula in the mask simply states that if a number is less than or equal to 4 (there are 4 quarters for a year), then return a number 1. Otherwise, return a zero. This mask can now be used to include or exclude quarters and annual amounts as in Figure 11-38.

Figure 11-38.  The calculation mask is used to include quarters but not years

The process is to multiply the quarterly numbers with the calculation mask, and anything that is multiplied by zero produces a zero. This way you can completely eradicate the annual amounts. The next part is to produce a table that just takes the yearly amounts and excludes the quarters; this step is slightly harder because you are now reversing the use of the zero and the one, as in Figure 11-39.

245

246

Chapter 11 | Calculations for Financial Modelers

Figure 11-39.  In this model, the calculation mask is used to include the years and exclude the quarters

Array calculations for single values In this section, I want to show you how to use array functions to solve calculation problems. Array calculations have their uses in modeling because they allow the modeler to create calculations that are tailored toward the results that are required. An array formula is a formula that works with an array, or series, of data values rather than an individual data value. There are two types of array formulas. The first type returns a singular value to a single cell and works with a series of data and aggregates it, typically using SUM, AVERAGE, or COUNT. The second type returns an array of values as their result into two or more cells. This section will demonstrate the use of a number of array calculations that are very practical for modeling and, in doing so, will offer the premise for using the array formula while still maintaining a best practice model. The first example is how to force a calculation on a series of data even when there is an error. Keep in mind that Excel is a very logical application. If it encounters an error for a series of data, then it’s impossible to make any calculations on the data series without picking that error. In other words, it won’t calculate just using traditional functions (see Figure 11-40).

The Handbook of Financial Modeling

Figure 11-40.  This model is using the average function as an array to calculate over errors

In the calculation, the formula is calculating an average cost per unit. But I have added in an extra dimension so that if an error occurs in the column where I am reading data (column D), then I can just substitute the error with blank data (“ ") and calculate the average. Otherwise, calculate the average as usual. (The syntax of the formula is not explained for the reason that it will be explained in the next section.) This array function is extremely useful because it can be used to check the inputs, and even if the inputs are in error, the calculation is still made. However, always be aware that when using such a calculation with averages, the result will be skewed because there is some missing data. Notice the curly brackets around the formula. Do not be tempted to place these yourself as they are automatically created when you press Ctrl, Shift, and Enter, which is how to create arrays.

Formulas that are based on a condition This next array calculation is based on creating a formula that will give results based upon a condition. Again, this is another classic example of a situation that comes up repeatedly in financial models. The SUMIF function, while extremely useful, is not capable of handling conditions beyond two dimensions without having to make a highly complex formula. I know of several modelers who are very uncomfortable with using arrays, but there is nothing to fear. Yes, it’s not good practice to have hundreds of arrays strewn through the model. But at the same time, you should be capable of using them when required to do so. In Figure  11-41, I have created a simple conditional calculation that illustrates the use of COUNT, but this can be expanded to take on several more conditions or used with SUM, AVERAGE, or even SUMPRODUCT.

247

248

Chapter 11 | Calculations for Financial Modelers

Figure 11-41.  This model uses the array calculation with conditions

Notice the syntax. The IF statement in Figure 11-41 is looking for two conditions in the table. The first condition is finding where the age is greater than 30, and the second condition is to find where the age is less than 40. The return is to show how many occurrences happen with these conditions. There is an IF placed for each condition. It is possible to have several more conditions (up to seven), but I would argue that anything beyond three conditions is excessive. At that stage, you would start to verge on using online analytical processing (OLAP) cubes, which will not be covered in this book. OLAP cubes would be used on tables of data and information where one row of data can have several columns of information because the formula is able to accommodate several conditions.

Getting the closest match to an input target This next array calculation is one that I have used in order to test the data for a specific target. Put simply, the formula allows the user to input a target, which can be text or a numeric value depending on which part of the data the calculation is referencing. By then entering the target inputs, the formula checks through the data range and picks out the item that comes closest to matching the target.

The Handbook of Financial Modeling This array formula is very useful for checking the tolerance in a date, for instance. When I create models that are required to receive a download of a CSV file from an external data store of personal data, I will often have this target input in place. This way, I can check to see any of the ages, for example, in Figure 11-42, are near 0 or 100, as that will provide me with highest and lowest tolerances. If the closest match falls below or above this range, then I can be reasonably sure that the data is lacking integrity.

Figure 11-42.  The input is used to set the target age, and the closest match is identified

Using crosstab calculations For those who have used relational databases such as Microsoft Access, you should already be aware of the crosstab. This is a method of summarizing categorical data by using an algorithm that searches between those categories. Crosstab calculations are far from essential to modeling, but they are useful, particularly for representing data in a logical manner. I use crosstab calculations mainly for presenting dashboards by creating tables that can easily be digested. Figure 11-43 shows how a cross table can be created with an array calculation.

249

250

Chapter 11 | Calculations for Financial Modelers

Figure 11-43.  A crosstab calculation is useful when presenting dashboards

Applying the right function to your calculations I am often asked if I can give some advice on which functions are best to use when modeling and which ones should be avoided. This then leads to conversations on which functions are best for specific calculations. You may be surprised by my response to these questions. I believe that there really are no answers because, unfortunately, not every calculation is identical. This is one reason why Excel has so many functions capable of achieving solutions for the equivalent calculation. Numerous functions are needed, because there are subtle differences that can have a significant effect on the result. With so many functions available, hopefully there should always be one that meets the modeler’s needs. Now that I have burst that bubble, let’s look at the positive. While I cannot give definitive answers as to which are the right functions to apply to calculations, I can tell why certain functions work better than others for specific calculations.

The Handbook of Financial Modeling

Functions that look up information The majority of calculations that are used in models are based on the lookup; that is, by using a key or reference, you can unlock further details that can then be substitutes and used through the calculation. There are several lookup functions, and some are more specialized for specific types of calculations. For instance, the function =GETPIVOTDATA is designed purely for getting an information from a pivot table and will not work properly unless it’s applied to a pivot table. The following three lookup functions are ones that all modelers should be familiar with ·· =VLOOKUP( ) ·· =MATCH( ) ·· =INDEX( ) In addition, the VLOOKUP( ) is also partnered by the HLOOKUP( ) function, and the MATCH function is generally combined with INDEX( ) which we looked at earlier in this chapter. The best way to learn these functions is to actually practice them. Get a worksheet and carefully go through writing the syntax, even with minimal data, just to begin to understand how the functions work and to start becoming comfortable with using them. I have one final note about these three functions. I always prefer to use the INDEX( ) MATCH( ) combination in contrast to VLOOKUPS, although this is a matter of preference. There are a number of potential issues in relation to computer processing capability with VLOOKUPS that steer me away from using it.

Functions that require a condition For calculations where a specific condition must be reached in order to get the correct result, the majority of go-to functions include the following: ·· =IF( ) ·· =SUMIF( ) ·· =COUNTIF( ) ·· =SUMIFS( ) ·· =AVERAGEIF( )

251

252

Chapter 11 | Calculations for Financial Modelers Do not allow yourself to go through this chapter without knowing how to use the =IF( ), =SUMIF( ), and SUMIFS functions They are the most important condition-driven functions you will ever get to use. In order to build a serious model, these will be your most useful functions for calculations reliant on the data held in another cell or when you require input from the model user.

Functions that are driven by dates Dates and times are always tricky because they just don’t work on a typical denary level and so require some conversions. In other words, if you try to add two dates together, the result will not be as you expect unless they are converted. In almost every model you create, you will need at least one of the following functions when working with dates: ·· =DATEVALUE( ) ·· =EOMONTH( ) ·· =WORKDAY( ) ·· =WEEKDAY( ) ·· =TODAY( ) ·· =DAYS360( ) ·· =YEAR( ) ·· =MONTH( ) All of these functions have their own merits in one way or another. You will seriously limit your ability to creating efficient, fast, and clear calculations if you neglect any of these functions.

Functions for precise situations Excel is seen as a financial application in many quarters and is really the most widely used application in finance circles today. One ironic aspect of Excel is that many of the popular financial functions have some odd quirks or just don’t feel complete. In other words, you generally need to have a strong financial background in order to use them. This brings us to our next point— many of these functions can be created in other ways, which means they have alternatives. There is a clutch of functions that have no alternatives and are used in precise situations that should be understood by modelers. The functions that you should always be able to use are

The Handbook of Financial Modeling ·· =DB( ) ·· =DDB( ) ·· =IRR( ) ·· =XIRR( ) ·· =NPV( ) ·· =XNPV( ) ·· =SLN( ) ·· =SYD( ) ·· =FV( ) For instance, the DB( ), DDB( ), SYD( ), and SLN( ) functions are all about calculating depreciation, while the NPV( ), XNPV( ), IRR( ), and XIRR( ) are for capital budgeting. However, you should still be familiar with how they work and be capable of applying them to calculations that demand that particular situation.

Mathematical functions All calculations are mathematical in one way or another, so why are some calculations described as specifically being mathematical? The reason why some of the functions are called mathematical is that they are designed to simulate a specific mathematical problem or solution. For instance, the SUM( ) function is mathematical because it is designed to calculate the total of a range of cells. When discussing mathematical functions in Excel, I am referring to functions that are built around particular math problems and their solutions. These functions are often too limited for general modeling, but there are some that have some major uses in modeling. Yes, you could get by without them, but you will find that having them greatly enhances your ability to create good calculations. Here is a list of the most commonly used mathematical functions in models: ·· =MOD( ) ·· =ABS( ) ·· =CEILING( ) ·· =INT( ) ·· =RANDBETWEEN( ) ·· =ROUND( )

253

254

Chapter 11 | Calculations for Financial Modelers ·· =ROUNDUP( ) ·· =ROUNDDOWN( ) ·· =SUM( ) ·· =SUMIF( ) ·· =SUMPRODUCT( ) ·· =SUMIFS( ) ·· =SUBTOTAL( ) You will immediately spot that a number of the functions appeared previously in other sections of this chapter, such as the SUMIF function. These functions operate on calculations in several ways, and so there are some that can be considered conditional or mathematical. Aside from the massive importance of SUM( ), which cannot be understated; SUMPRODUCT( ) is another mustknow function because it saves an enormous amount of time and effort when used correctly. All of these functions mentioned in this and the previous sections should be part of the modeler’s armory, and not one should be neglected.

Functions dependent on text In an ideal world, you wouldn’t need text functions in Excel because after all, Excel is not a word or text tool. However, the reality is text is part of the data and information that modelers routinely work with. Being able to do even relatively simple calculations like extracting the last name from a lump of text is very important. This list of text functions is critical to know because you will always need them in a model and they will save you time: ·· =FIND( ) ·· =LEFT( ) ·· =MID( ) ·· =RIGHT( ) ·· =LEN( ) ·· =REPLACE( ) ·· =TEXT( ) ·· =TRIM( ) ·· =VALUE( )

The Handbook of Financial Modeling Without exception, all of the listed functions are critical to know because they help you deal with the more common problems that afflict modelers. For example, these functions can correct the data that is inconsistent from row to row or when you need to extract first names and last names and some of the names have middle names and others do not.

 alculations involving logical and information C functions Logical functions are about adding functionality rather than making pure calculations, and so they are not always critical. However, being capable of building error checking and being competent to work with unknown issues are what differentiate good modeling from standard modeling. These functions should also be part of the modeler’s kit: ·· =IF( ) ·· =AND( ) ·· =FALSE( ) ·· =TRUE( ) ·· =NOT( ) ·· =OR( ) ·· =ISERROR( ) ·· =ISBLANK( ) ·· =ISTEXT( ) ·· =ISNUMBER( ) ·· =CELL( )

Math in modeling How much of financial modeling is about math? Or to put it another way, does the modeler need to have an above average grasp of math to succeed? These questions are valid and also have a lot of gravity, mainly since modeling has yet to be defined. Does it fall into the category of science, business, IT, mathematics, engineering, or commerce? Because so many modelers have accounting backgrounds, it does seem as if modeling falls somewhere between business and math, but I am not convinced on that score.

255

256

Chapter 11 | Calculations for Financial Modelers I will discuss math—specifically how much math is involved in modeling and what aspects of math should the modeler be ready to apply. In order to investigate this topic, a few examples of calculations and solutions that are commonplace in modeling will be discussed. Before launching into the examples, I want to first explain one aspect about modeling and math: BODMAS.

BODMAS BODMAS stands for Brackets, Order (Power), Division, Multiplication, Addition, and Subtraction. This is the foundation of how to perform calculation orders in mathematics, and this is how Excel will always interpret calculations. Therefore, it makes sense that modeling would use the same order. So, with BODMAS, how would you order a calculation? In the United States, this can also be referred to as PEMDAS: Parenthesis, Exponents, Multiplication and Division, Addition, and Subtraction: 4 + 8 x 2 -10 x 6/2 The simplest way to solve this equation is to look for the order of BODMAS in relation to the calculation. Brackets

None

Order

None

Division

6/2 = 3

Multiplication

8 x 2, 10 x 3

Addition

4 + 16

Subtraction

20 – 30

Because this may still feel complicated, let’s go a step further. The BRACKETS part is very important because it is the first operation that will be executed. As long as you use brackets, you can force the order to execute how you want. When creating calculations that have a mix of operators, always use the brackets to control the order. From a modeling standpoint, this is good practice because it then becomes clearer exactly which operations are executed first to last. For the previous equation, rewrite it this way: (4 + 8 x 2) – (10 x 6/2) This will give us this equation: 8 x 2 = 16 + 4 =20 20 – 30 = -10

-

6/2 = 3 x 10 = 30

The Handbook of Financial Modeling Understanding BODMAS and correctly applying this order is so critical to modeling calculations. If this subject is difficult for you to understand, purchase a math book and make the effort to gain a solid understanding of it. Excel will always use the BODMAS order to evaluate calculations. If you are unclear on this order, the results from your formula calculations will not match expectations. And because your understanding of the orders is unclear, you will be unaware that the calculation is wrong.

The math in formulas Fortunately, there is not a lot of math that the modeler needs to apply because most of it is already captured in the functions. It may surprise you that I know many modelers who do not have a mathematical background and actually consider themselves weak in math, but nonetheless they are modelers. The main difference is that they are comfortable around numbers and are not overawed by them. The math that comes in modeling is the ability to perform calculations and recognize the functions that are most appropriate like the those in Figures 11-44 and 11-45.

Figure 11-44.  There are a number of functions that sum cell ranges, and each should be applied against the structure of the model calculations

257

258

Chapter 11 | Calculations for Financial Modelers

Figure 11-45.  This figure shows the count functions and arithmetic that will be required in the majority of models

Conclusion on calculations There are literally hundreds of functions which perform calculations in Excel, most of which should only be applied to specific situations and conditions. Once you are familiar with the functions and calculations we have looked at in this chapter, you will have most of the calculations you will ever need to build commercial sound financial models. When it comes to using functions and making calculations, the difference between a good and exceptional financial modeler economy and efficiency. Exceptional financial modelers will use just a handful of functions throughout the whole model, and the calculations will be compact and easy to follow with no hard-coded numbers.

CHAPTER

12 The Importance of Documentation In this chapter, I will examine the process of providing user documentation for models. Without question, one of the most neglected stages of building models is documentation, because often it is performed toward the end of the modeling project and subject to time constraints. This is a short chapter but a very important one because documentation in financial modeling is far too neglected. I want to make sure that you have a firm understanding of why documentation should be considered just as important as any other stage in modeling.

Providing documentation in models The financial modeler should keep a log of all amendments made to the model to ensure a proper audit trail and documentation of changes made. A guide to using the financial model should also be developed to make certain that future users are able to become familiar with and use the model with ease. Just as writing the specification often seems like a mission in complete boredom, writing the documentation can be very mundane. The unfortunate truth is there are far too few examples of documentation in financial modeling, possibly due to this boredom factor. Another reason why documentation is not completed or even commenced is due to timetables. For example,

© Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6_12

260

Chapter 12 | The Importance of Documentation sometimes the point from beginning to handing over or implementing a model is very short, and there is barely enough time to even test the model. Finding the time to document a model under such circumstances may seem impossible. Documentation, however, almost always needs to be done. The model that you develop could be responsible for helping to form decisions that have a significant financial impact on a project or an organization. Therefore, it is imperative that some details of how and why the model works accompany the model. Documentation is like the contents section in a study book; it puts into place where everything is located and how it all works together. Without it, you are blindly trusting that the book will actually take you to where you want to go. Good documentation is needed to ensure that the model is handled properly, even by users who were not involved throughout the development process. Ideally, your specification will serve as the basis for the user documentation. Remember that the better your specification, the more of it you can “recycle” in the final user guide. The secret to documenting is to start as early as possible and keep on top of it each day. Avoid procrastinating because the longer it is left undone, the harder it will become to finish. During my model builds, I make sure the documentation is always performed at the end of each day and reviewed the following morning before carrying on with the model development. Another tip is to employ what I call “spot checks,” whereby I choose a particular part of the model and check that there is documentation. I won’t move on until that part is in place. Often, I will nominate an independent party who will check through the parts of the model and through the documentation to test if everything makes sense (not someone with the immediate modeling team but someone who is totally removed from the model build).

Documentation structures Consider that not all users of the model will be Excel “power users.” If you know this will be the case, then it is imperative that there is some additional care placed on the documentation. For example, you will need to explain what a macro is before you explain what your macro does and do the same for model checks before you explain how a user can go error hunting. Here is one way to organize the structure of your documentation.

Introduction The first section of your documentation should explain the scope and the goal of the model. The user should understand what to use the model for and what to expect from it.

The Handbook of Financial Modeling

Assumptions and inputs Following the introduction, explain the structural assumptions and the relevant inputs. The user also needs to understand the interaction between the assumptions and the inputs. For instance, if any of the assumptions are subsequently changed during the modeling process, will the inputs automatically adjust to reflect this change, or will someone have to manually adjust the inputs?

Macro handling If the macros in the model are complex and require some user proficiency, include a section on handling macros. Depending on the client, this may even become technical with some code explanations. In simpler models with no (or automatic) macros, you may drop this section.

Outputs One chapter should be dedicated to the output sheets. In this section, 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).

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 too far from reality. Typical issues may include the following: ··

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 should also explain the reason, for example, if this is due to a calculation 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.

261

262

Chapter 12 | The Importance of Documentation ··

Compatibility issues: It happens rarely, but include in your documentation if you know your model has problems with certain versions of Excel (or Office), Windows, locale settings, and so forth.

Documentation standards Documentation is crucial to models. Irrespective of whether a model has it or not, every model should be documented. How that documentation occurs can be wrapped up by a generally accepted documentation standard.

Using cell comments Cell comments are a way of communicating tips and instructions to users. When a user’s cursor hovers over a commented cell, a text box appears displaying the message. To add a cell comment, right-click the cell you want to attach the comment to and choose Insert Comment. A yellow text box will appear with an arrow pointing to the activated cell. Type in your comment. When you are finished, click any other cell. The comment will be saved, attached to its anchor cell. The anchor cell will show a red triangle, indicating that a cell note is attached. (Note: The red triangle can be turned off by the Options dialog box, by choosing the Advanced option and scrolling down to Display.) If you have many comments in your worksheet, you might use the Reviewing toolbar to manage them. Different buttons on the toolbar allow you to add comments, delete them, show all comments on the sheet, and tab from comment to comment. By default, cell comments do not print when you print a worksheet. If you want comments to print, change the Comments setting in Page Setup. You have the choice of printing no comments, all comments at the bottom of the sheet, or as the comments appear directly on the sheet. Documentation worksheets Should you find that the instructions and explanations for a particular workbook are too unwieldy for cell comments, consider adding a separate worksheet in the workbook that contains only instructions and explanations. Give this worksheet tab a descriptive name, such as “InstructionsToUser” or “ModelnameDocumentation.” Excel’s word processing capabilities are very limited, making editing of long text entries tedious. People often try to use Excel as a word processing tool, but that is just not in its bag of tricks. Don’t fall into this habit as well. If you need to create considerable text documents in Excel, consider using MS Word and object linking the document to Excel. If you must use Excel, however, take these steps to make entering and editing long text passages easier:

The Handbook of Financial Modeling ··

Format cells with the Wrap Text feature turned on. To activate this feature, on the Home tab, in the Alignment group, click Wrap Text.

··

Consider widening column A and using it for all entries.

··

Always segment instruction topics into separate rows to minimize alignment problems when text is changed.

Thoughts about the application to be used At some stage, the specifications will be locked down, and you will be in a position to begin developing the model. But first, put some thought into the application in which the model will be designed. Although you may already know you will be using Excel for modeling, consider that even with Excel, there are different versions that can alter how you build the model. It is a safe assumption that your model will be developed in Excel 2007, Excel 2010/2013, or Excel 2016. The essential modeling is the same throughout; however, the ease of development becomes more apparent in the later versions. Spreadsheet packages are good at numerical manipulation and have a wide range of financial and mathematical functions. It is easy to present calculations in a readable form and to mix text and graphical display. Spreadsheets are enormously popular, widely available, and easy to use. The flexibility of spreadsheets makes it possible to use them to tackle problems that would be more appropriately modeled with different software. Their availability and ease of use make this an extremely common mistake. Therefore, before you design a spreadsheet, make sure that a spreadsheet is the most appropriate tool for the job. Excel 2016 has a wide range of add-in functions that allows you to do numerous unusual calculations. Many of these can be very useful, but if you find that you are using them often, you would probably be better off using a specialist package. For example, if you are using a lot of the database functions, then you should consider incorporating power query into your models. It’s quite possible that what seems at first to be a financial modeling project is really an exercise data reporting and dashboards in which case you should consider whether the right tool is business intelligence tool like Power BI, Tableau, or QlikView. This chapter is an augmentation to the planning of the modeling process. When working on medium to large models, there is so much that can be gained from having a plan with all the stages clearly established. I have come across completed large commercial models where there has been no documentation whatsoever. In my opinion, these models are not complete if they lack documentation.

263

CHAPTER

13 Model Stress Testing There are no standard tests for financial models, but there are a series of test types that are used. Not all of these are appropriate for each model, and in order for the tester to understand which test types will be right for the model, the tester must first understand the model. The testing is never incidental; it doesn’t just happen because the model has been built. It is a carefully planned and organized activity that has a significant part to play in the delivery of the model. Therefore, it is a critical part of the model design. Model testing is far from being an established business practice, so the options are not as clear, although there are a few software applications that work well. Few commentators recommend or even mention model testing, as the model audit is the established method of providing model assurance. However, both testing and model audit are complementary; they need not go head-to-head because they are based on differing ethos. The following is a summary of the standards of model testing: Models are developed by humans: the very same humans who make errors that can have a significant effect on a model’s behavior. Model testing is about discovering those errors and measuring their relationship with the behavior of the model. Thus, testing is about the quality of the model.

© Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6_13

266

Chapter 13 | Model Stress Testing To put it simply, testing is quality control, while model audit is assurance. If we look at it on this level, then these two processes augment each other. In my view, testing should be performed during the model building so that the errors can be caught and mitigated as part of the development and checked. Testing should look at those errors and how they affect the overall quality of the model.

Why test? A best practice spreadsheet model should be reliable because decisions are likely to be made based upon the results and outputs that come from the model. This is only possible if the user has complete confidence in the model. It is impossible to guarantee that even a moderately complex model is an error-free model. Testing can, however, substantially reduce the risk of significant errors in a model. If I had to estimate the number of commercial use financial models that go through testing, I am quite sure the number would be low for the following reasons: ··

Model testing has yet to be established as a stable and bona fide business practice. Therefore, there are very few model testing practitioners.

··

Most organizations that use financial models are satisfied with a model audit, which in the main has a proven track record for delivering value for money.

··

Little is understood of what is required to test a model, so there are few instances of in-house testing.

··

More often than not, the timescale involved when developing financial models is very tight, and as a result, model testing is seen as a “nice to have” option that will be included only if time permits.

Although it may be currently not included in mainstream modeling, model testing is nonetheless critical. Testing is the only way to provide any guarantee that the model not only works, but it also stresses the conditions in which the model will continue to work and when it fails to work. As an analogy, can you imagine buying a cell phone, understanding that the phone will allow you to make and receive calls, but not knowing under which conditions the phone would not work? For instance, most of us know that our phones will not work if exposed to extreme temperatures or moisture, when there is no cell mast in close proximity, or if the battery is continually being undercharged. These examples of when cell phones do not work are based on testing. We only know this information because the cell phone has undergone numerous tests.

The Handbook of Financial Modeling I believe that financial modeling will at some point have to embrace model testing wholeheartedly, just as the software industry has done. As models have now become more vital to everyday business, they will need some amount of stress testing in order to become a business mainstay.

Who should test? When testing a model, the objective is to demonstrate that the model does not work as it was intended. From this standpoint, the testing can focus on catching all the aspects in the model that are causing it to fail. It is impossible for modelers to be sufficiently critical of their own work; therefore, testing should always be carried out by an independent third party. It is best for testing to be done by a team member who has been involved in other aspects of the overall project or aspects of the modeling other than the design and build. There are obvious benefits to using someone who is familiar with some of the issues that the model reflects. However, the technical skills required for a good tester are similar to those required for building the model. The tester should be able to understand and critique the detail of the formula and any code within the model.

When to test? When should testing commence? This is entirely based upon the program schedule. Testing, however, can only take place between the build and handover stages of the modeling life cycle. Under more pressing circumstances, it can be more difficult to identify the most appropriate time to test. Here are two examples: ··

When there is great pressure for immediate results from the model, there is a trade-off to be made between gaining confidence in the model’s results and trying to produce some reasonable answers quickly.

··

When the model develops in a number of incremental stages, it is difficult to know when the time is right to first test the model or when further changes are significant enough to require retesting.

There is no single correct answer for these questions, but there are points in time when testing should be considered. Generally, the testing period would commence just after the first version of the model is completed and run until all the errors are fixed and recommendations are implemented into the final model version. With very complex modeling projects, however, the modeler

267

268

Chapter 13 | Model Stress Testing should consider implementing testing into the change control process. This way, testing will take place at regular intervals and after every major change in the model. This will be surplus to requirements for smaller models and can be costly. But with this approach, the model will always take into consideration any errors that are highlighted from testing.

Types of tests One of the unfortunate aspects of model testing is that there is no standard test. Instead, there are different types of tests that can be used, but not all of them are appropriate for every model. This dilemma of test choices is one reason why it is best for the tester to have spent some time with the modeler in order to gain an understanding of the model’s structure and objectives. The next sections will provide brief summaries of the main model tests. These procedures are based on software testing using the software development life cycle (SDLC) because these tests are most appropriate to modeling. The key to testing is the methodology behind the test results. For instance, a test report represented by a percentage such as 60% could mean 60% of all errors in the testing type will be caught in the first round of tests, or 60% could be caught after two rounds of tests, and so on. Clearly, the lower the percentage, the more critical that several test rounds are pursued as the percentage of errors not caught will decrease. In each of the tests, the detected errors are identified and then fixed by the modeler before the model continues on to development.

The test plan Prior to commencing any testing, one vitally important task is to create a test plan. The test plan is a document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, and who will do each task. An example of a test plan is shown in Figure 13-1. It should also identify any risks involved with planning the tests and contingencies for those risks. If the entire idea of a test plan just seems far too formal, then you should keep in mind that the testing phase can be detailed and complex. It’s very easy to lose track of which tests yielded which results and any issues and corrections that were made.

The Handbook of Financial Modeling

Figure 13-1.  The headings with a typical test plan document are shown here

The test plan allows for the planning; without the plan, it is unlikely that the tests will yield any success. Crucially the test plan should never be created by the modeler; this is the domain of the chief tester. There should be as little interference from the modeler or modeling team as possible. When I have performed tests on models, I will allow the modeling team to review the test plan once it has been finalized, but no one from the team is given the chance to change or make any amendments. Nor does the modeling team get the chance to provide any additional material that may interfere with the test. If this were to happen, I would reject the said material and report it as an issue in the test report.

269

270

Chapter 13 | Model Stress Testing

Numeric tests Numeric tests are used to determine if the outcome of an equation is in accordance with expected results by using an independent verification as a check. There are various ways to subject the results from a model to independent verification, including the following: ··

It may be possible to reproduce some of the model results by hand or in a “quick and dirty” independent model.

··

When the model is developed to replace a precursor model, any similarities or differences in common results can be explained by differing assumptions.

··

When you know that there will not be time to test the model, ask two modelers to independently do the analysis and then compare their results.

A well-designed model will contain some internal numerical tests. A balanced balance sheet and consistency between calculated totals and subtotals are both necessary signs of a reliable model, but they are not proof that no errors still remain in the model. You will only get sensible results out of a model if you put realistic input assumptions in. While it is often outside the scope of the independent tester’s work, the validity of the input assumptions will obviously affect the appropriateness of the answers.

Robustness tests The longer the expected life span of the model and the more different users of the model there will be, the more difficult the model test becomes. Instead of testing the validity of the model just under current circumstances, the tester needs to consider all the feasible circumstances that the model may be used for in the future. The two categories for robustness testing look at the environment that the model will operate in and the boundaries at which the model will potentially fail.

Environment tests Environment tests evaluate the operation of the model through several different computer configurations. Points to check include the hardware specification of the computer to be used, network and printer operations, and the specific versions of software being used. These tests will confirm that technical specification has not been exceeded, in particular the model size and calculation speed.

The Handbook of Financial Modeling

Boundary tests Boundary tests assess the behavior from the model when inputs reach sensible limits. For example, these tests would answer the following questions: ··

How does the model cope with extremely large or extremely small inputs?

··

Does typing in a zero-produce division by zero errors?

If you type junk into a model, you expect to get junk out. But for many models, some form of data validation may be appropriate. Nevertheless, extreme cases of using particularly good or bad input assumptions are often important sets of model results, so the model should be able to cope with these.

Macro tests If the model contains macros, testing these can be extraordinarily timeconsuming. Macros often only cause errors in a particular circumstance, which the tester will need to replicate to get an idea of how the error happens. The following issues are typical of the checks: ··

Do the buttons, dialog boxes, and menus work appropriately?

··

How does the macro cope with inappropriate data? How elegantly does it crash?

··

If the macro involves file handling, what happens with duplicate or nonexistent files?

··

Does the macro assume any default settings for the spreadsheet, such as sheet names, which a user may change?

··

What happens when the user presses Escape during the macro execution?

When enough changes have been made in the model since the previous test, it makes material changes to the results possible. You need to consider how big a change to the results constitutes a material change and should then fall into the change control process.

271

272

Chapter 13 | Model Stress Testing

Specification tests One of the objectives of the specification stage is to establish a common understanding of how the model should work. To achieve this objective, it is necessary to test that the specification agrees with the model sponsor’s understanding of what the model will do. Clearly, this process does not require the model build to have been completed or even started.

Unique formula tests To test that the formulas in the model have been written correctly, check the model itself against the logical assumptions described in the model specification or in a similar document. A review of every unique formula in the model is an essential part of any thorough model test. Even so, the number of formulas in a reasonably large model makes this a daunting task. I recommend resolving this problem by using the formula maps produced by a spreadsheet auditor package, such as OAK.

Black box testing Black box testing takes an external perspective of the model in order to derive test cases. These tests can be practical or nonfunctional, though they are usually functional. The test designer selects valid and invalid input and determines the correct output. This method of test design is applicable to all levels of software testing: unit, integration, functional testing, system, and acceptance. The higher the level, and hence the bigger and more complex the box, the more one is forced to use black box testing to simplify. While this method can uncover unimplemented parts of the specification, the tester cannot be sure that all existent paths are tested.

White box testing White box testing is a security testing method that can be used to validate whether code usage follows an intended design, to confirm implemented security functionality, and to uncover exploitable vulnerabilities.

Error handling testing Error handling refers to the anticipation, detection, and resolution of programming, formula, and communications errors. Specific formulas are created as error handlers.

The Handbook of Financial Modeling

Compliance or static testing Compliance testing is all about checking to what degree the model is working as per the set standards of the organization. These standards can be for the outputs (financial statements), styles, wording, macro coding, how the data is organized, confidentiality, change control or issue handling capabilities, how the model is integrated into in-house systems, and also how the model is deployed. On basic-level compliance, testing is an inspection of the model with a checklist to test the quality of conformity. Therefore, the starting point is always a list of standards that the organization requires from all models or spreadsheets and a check against them. Figure  13-2 is a typical compliance test checklist that I have used in model tests.

Figure 13-2.  A typical compliance test checklist is shown here

The criteria that would be used during testing would be ··

Name of test: The name should reflect the type of test.

··

Test type: This is the type of test conducted, which should match the test plan.

··

Section name: The part of the model, for instance could be a worksheet or input section.

273

274

Chapter 13 | Model Stress Testing ··

Test ID: This is a reference to the test; each test and test round should have a sequential reference.

··

Test date: This is the date when the test was carried out and should be in synchronization with the iteration and test round.

··

Iteration/test round: A number that shows how many tests have gone before this one.

··

Severity: This is a code that summarizes the results of the test in that round.

··

Number: This is a sequential number for the order of the criteria order.

··

Test step description: This is a description of what is being tested.

··

Result description: This is a description of the result of the test for that criterion.

··

Steps: The drop-down gives four options that will reflect the result of the test: pass, fail, N/A, and waived.

··

Observed results in case of fail: If the test fails, it is imperative to describe exactly what was observed as it is possible the failure was the result of an external matter and not the model.

··

Waiver description: This is a description of the potential impact to the end user if the test fails.

··

Other comments: This is for any further comments that are deemed necessary.

Management control testing Management control testing is used to evaluate the level of control in the model. For example, this would look at the inputs to test if it is possible for one input to have an effect on several calculations. This differs from compliance testing because it is all about the processes and edicts from management, which are current at the time. For instance, management may stipulate that data should always be accurate and not hypothetical, that all transactions should be authorized by senior figures, or that there should be an audit trail for all assumptions.

The Handbook of Financial Modeling The major criteria that would be included in the test are ··

Control: This is the name of the control as prescribed by management.

··

Identified risk: This is the prevailing risk associated with this control.

··

Controller: This is the name or contact of who is responsible for the control.

··

Overall result description: This is the test case result: pass, fail, N/A, and waived.

··

Comments: These are any comments that can provide some detail behind the overall test case result.

Stress test Stress testing deals with the quality of the application in the environment. The idea is to create an environment more demanding of the model than the model would experience under so-called normal work use. This is the hardest and most complex category of testing as it is totally based on the model design. Conflict conditions, for example, where an input for taxation rate also affects the inflation rate, and system capacity issues are two of the most common errors that will come out of stress testing. The method used to get results for the two conditions is to run two tests in parallel: one is looking for conflict and the other is examining the system capacity. The tester is looking to see if one or both tests fail because they either negate each other or create an unforeseen equation to emerge. This is what happens when inputs, calculations, and outputs have not been designed in the correct order. In Figure 13-3, a sample is given of the test that I use. This stress test allows the tester to set up to five input parameters by using the drop-down to choose between very low, low, normal, high, and very high. By mixing and varying input parameters, the tester can review the behavior of the model under a mix of conditions and thus stress the model.

275

276

Chapter 13 | Model Stress Testing

Figure 13-3.  A template of a stress test is shown here

System performance test With this type of testing, the systems under which the model is working are tested, and then differing configurations are also tested. The network performance is also tested under different levels of user usage. This may involve testing the model on the network during the morning, afternoon, and evening. The model is placed in a calculative state. In other words, the model is induced into processing data, and subsequently a system’s performance tool can then be used to compare the processor performance. There are tools available that are able to measure performance, which is generally assessed in terms of response time and throughput rates under differing processing and configuration conditions.

Functional testing Functional testing means testing the model against business requirements. In this type of testing, the tests are written in order to check if the model behaves as expected. Although functional testing is often done toward the end of the development cycle, it should be started much earlier. Individual components and processes can be tested early on, even before it’s possible to do functional testing on the entire system. Functional testing covers how well

The Handbook of Financial Modeling the VBA code (if there is any) executes the functions it is supposed to execute, including user commands, data manipulation, searches and business processes, user screens, and integrations. If there is just one test that is a must, it is this one. Functional testing always verifies that the model is fixed for release. Functional tests also define your working model in a useful manner. With this type of testing, the tester has to validate the model to see that all specified requirements of the project and customer are met. Functional testing is always concentrating on customer requirements.

What do you test in functional testing? These are the main areas that are tested with functional testing: ··

Mainline functions: The main functions of an application are tested.

··

Basic usability: This involves fundamental usability testing of the system and checks to see whether a user can freely navigate through the screens without any difficulties.

··

Accessibility: It checks the accessibility of the system for the user.

··

Error conditions: It checks for error conditions to see whether suitable error messages are displayed.

The testing process will consist of the following: ··

Understand the requirements.

··

Identify test input (test data).

··

Compute the expected outcomes with the selected test input values.

··

Execute test cases.

Compare the actual and computed expected results.

How to test your model Model testing is very much in its infancy, and it is certainly not as highly developed as software testing. The information presented in this section is something to aim for; as mentioned before, this is not in general practice today. However, it should be something that modeling will need to have as part of its life cycle. Although I use this type of methodical approach to testing models myself, this area of modeling is very much exploratory.

277

278

Chapter 13 | Model Stress Testing Testing is an important part of model development. It should always be started as early as possible and should be part of the process of deciding model requirements. You will find that it is worthwhile to provide time for the testing during model development as it will give a guarantee that the model quality is high. Testing is part of a model life cycle. The model development life cycle is about developing a credible tool that will fulfill the requirements of the users, stakeholders, owners, and other people who have an interest in what the model does. Hopefully, their requirements can all be captured in the model in the first development cycle. However, if there is a need for additions or changes, then the cycle must continue and that would include testing. Testing is a proxy for the customer. You could conceivably perform your testing by releasing it to the customer. Then, you would wait for the complaints and compliments to come back from the customers. But you are always in a better position to try and make sure that the model will satisfy the customer before you hand it over. Therefore, it is better to design tests based on the stakeholders’ needs and run the tests before the product reaches the users. Preferably the testing should be done well before then, so as not to waste time working on something that isn’t going to do the job. In this light, two important principles become clear: ··

Tests represent requirements. Whether you write user stories on sticky notes on the wall or use cases in a thick document, your tests should be derived from and linked to those requirements. Devising tests is a good vehicle for discussing the requirements.

··

You are not finished with the model until the tests pass. The only useful measure of completion is when tests have been performed successfully.

These principles apply no matter how you develop your model.

The testing cycle The testing cycle is as follows: ··

The modeler provides the model requirements to the tester and gives a detailed view of the model development concerning the requirements.

The Handbook of Financial Modeling ··

The tester creates a test script(s) based on the requirements but will have no input or interference from the modeler during this stage. The test scripts are a description of which aspects of the model will be tested and which types of test will be performed. The upshot is that each requirement will have its own test case, which will be tested.

··

When the model is in a usable version, it is made available to the tester, who will now commence with physical testing.

··

Any issues and errors that are discovered are passed on to the modeler, and a round count is concluded.

··

The tester will review the results of each round of tests with the modeler for quality and effectiveness of the implementation of the solutions. Also, at this stage, the tester using the previous round of tests as the baseline will subsequently decide whether another round of testing will be required later.

··

Once the reviews of the modeler and tester have reached a level where the tester deems the results to be of sufficient quality that no more testing is required, the tester will sign off on the tests.

··

Following the tester’s sign-off, the modeler will get approval from the sponsor that the testing phase can be concluded. The model has now been tested and is ready for lockdown final documentation and handover.

In view of the stages of testing, the unfortunate reality is that the time required for testing is often underestimated. There are usually concerns that the project timescales will be compromised unless the model can be completed on time, so the testing is concluded prematurely. Therefore, it is vitally important that the modeler provide beforehand a realistic and reasonable estimate of time in the project timescales for testing. This is possibly the biggest reason why testing is not always performed or performed poorly. Testers are not responsible for setting the timescales and must be placed in a position where they have the freedom to properly test and give a sign-off with no caveats or further issues that need resolving. In the past, I have compiled a checklist (included next) that is used after the model testing, approved, and signed off. Many of the items on this checklist are not always appropriate for all models, so you should use your best judgment to adapt it to suit your particular environment.

279

280

Chapter 13 | Model Stress Testing

Model development Is a project manager assigned to the project? Is the model development methodology divided into a reasonable number of phases? Are there management checkpoints at the end of each phase? How frequently is the progress reported to the project manager? Model change control

Does the model have a version number? How many modelers have access or are developing the model? Does the model’s change request form tally with the actual changes made to the model? Did the modeler write comments on the model? Were there any emergency changes made to this model? If so, when were they made and when were they checked and authorized? Is the user manual updated after a major change to the model?

Separation of duties

Are development and testing facilities separated from operational systems? Have the duties been separated to ensure that no one individual performs more than one of the following operations: Data origination? Data input? Output distribution? Are the functions of the preparer and verifier adequately segregated?

Data handling

Are errors displayed or printed immediately on detection for immediate correction by the user? Do error messages provide clear, understandable, cross-referenced corrective actions for each type of error? Are error messages produced for each input containing data? Are transaction rejections, caused by data entry errors, corrected by the terminal operator? Are there checks to ensure that the correct data files are used? Is there a logging-type facility (audit trail) in the model to assist in reconstructing data files? Does the model support concurrent or multiuser data inputs?

Connectivity

Is the model using connectivity such as ODBC or MDX for Oracle? What are they? Does the model have application program interfaces (API)?

(continued)

The Handbook of Financial Modeling

Model development Is a project manager assigned to the project? Independency

Is this model tested independently of the modeler(s)? Are end users involved in independent testing? Does the independent testing include testing of documentation? Does the independent testing analyze the manual portions of the model? Are independent test reports prepared? Does independent testing validate all the support systems on the model, including user procedures and backup procedures? Does the independent testing analyze the adequacy of the system of internal control? Does the independent test group understand the business nature of the model being tested?

Functional specification testing

Has the end user agreed that the defined requirement is correct? Did the end user participate in the development of the requirements? Is there a user sign-off at the end of the requirements phase? Do the requirements define the limits of possible changes to the data volumes during the expected life of the application system? Was an analysis of security requirements carried out at the requirements analysis stage of the project? Have the security requirements been identified and agreed upon prior to the development of the application system? Have appropriate security controls including audit trails been designed into the model? Is an audit trail part of the functional specification?

Test error conditioning

Has a brainstorming session with end users been performed to identify functional errors? Have functional error conditions been identified for the following cases: Rejection of out-of-range values? Rejection of invalid dates? All blank conditions in a numeric cell? Negative values in a positive cell? Positive values in a negative cell?

(continued)

281

282

Chapter 13 | Model Stress Testing

Model development Is a project manager assigned to the project? Negative balances in a financial account? Test for numeric cells? Blanks in an alphabetic field? Values longer than the field permits? Totals that exceed the maximum size of total fields? The model state

Has the state of empty tables been validated? Has the state of an insufficient quantity been validated? Has the state of a negative balance been validated? Has the state of duplicate inputs been validated? Has the state of entering the same transaction twice been validated?

Model implementation

Are model defects apparent before being handed over? Is the end user aware of model deficiencies before handover? Are detailed handover plans prepared before handover?

Model training

Are users trained in operating the model? Are the training materials consistent with the updated model? Are the training needs assessed? Is the operations staff informed of how to handle all abnormal conditions of the model, such as abnormal terminations or functions that fail to yield results?

Model backup strategy

How frequent is the data backup? How frequent is the model backup? Are copies of the model and data stored offsite? Is the backup tested on a separate machine to confirm recovery? Is there a procedure for recovery and business continuity including manual work required in case of a disaster? How long does it take to set up the model on a new machine?

Security and access

Are VBA codes protected from unauthorized access? Is model documentation protected from unauthorized access? Has all confidential information been identified? Have the potential consequences of unauthorized disclosure been assessed?

(continued)

The Handbook of Financial Modeling

Model development Is a project manager assigned to the project? Are only those who have a “need to know” authorized to access? Is information transmitted over telecommunication networks encrypted? Is storage media containing sensitive data and programs stored in a securely locked area and protected from unauthorized removal? Is test data protected and controlled? Has the sponsor reviewed the model authority levels in the event of a purported or real security violation?

Common types of errors to test Fortunately, there are some errors in models that are very likely to occur, and an experienced tester will be able to quickly target those errors in the model. Once these errors have been corrected, the more unique errors can then be tackled. The next few sections will describe the more common errors.

Formulas not copied With this error, a formula needs to be reflected either across a row or down a column, but it has somehow been missed and is not copied into all the required cells. There are several reasons how this would happen. In Chapter 2, the reasons why specific types of errors occur were discussed, such as the modeler talking on the phone while modeling. This type of error is quite difficult to locate, particularly if you have an erratic design for the model because a tester will be unable to be definite if the error is actually an error or if it is intended.

Wrong reference Nearly every formula in a spreadsheet refers back to another input or calculation. With the quantity of references in any large spreadsheet, it is inevitable that you will make mistakes and refer to the wrong cell (a pointing error). Sometimes, the resulting formula will produce a meaningless result, making it easy to spot with some simple numerical testing. If you are unlucky, the error in the result will be more subtle. While these types of errors are common, the testing should catch these quite easily. One way to alleviate these errors is to get into the habit of actually pointing to the cell that is being referenced rather than just naming it. Although this is a slower modeling process, it is more precise and mitigates the potential risk of using incorrect figures.

283

284

Chapter 13 | Model Stress Testing

Sum over the wrong range A similar mistake is to include the wrong cell reference in a SUM formula. It is particularly easy to introduce this error when you insert an additional row in a block of cells that are being summed. If you insert a row in the middle of the block, the formula will automatically adjust to include the additional row. But if you insert a row immediately above or below the block, the new row will be omitted from the formula. This type of error should be picked up in the error checks built into the model.

Relative and absolute references Another commonly found error is caused by confusion between relative and absolute references. Remember that a cell reference in a formula of the form =D4 will change if you copy the formula across the row to E4, F4, and so on. Copied down a column, it will change to D5, D6, and so on. If you use the reference =$D$4, it will not change when copied across or down. You can also use semiabsolute references in the form $D4 or D$4. The most common mistake is probably to use a relative reference instead of an absolute one. This is easy to spot numerically, but if you use an absolute reference in place of a relative one, it can be much more difficult to detect. The only way to find this mistake reliably is to use a formula map to go through all the unique formulas in the spreadsheet.

Unit errors Mixing up the appropriate unit for the elements in a calculation is another frequently occurring problem. Especially common is confusion between the order of magnitude for inputs, such as $s vs. $000s. This error should always be caught in testing. The modeler should be able to avoid making this type of error purely by making sure the units are clear and constant throughout the model.

Commonly misused functions Certain functions are frequently used incorrectly. For instance, the most commonly misunderstood is the NPV function, used to calculate net present values. The NPV function takes the form =NPV (rate, value1, value2, etc.) where a rate is an appropriate discount rate and value1, value2, and so on are a stream of cash flows to be discounted. One common error in the NPV function is using an inappropriate discount rate, especially when the model contains calculations in a mixture of real and nominal prices.

The Handbook of Financial Modeling A second common mistake concerns the timing of cash flows. By default, the NPV function assumes that all cash flows occur at the end of the time period you are considering. For an ongoing business, it is usually more appropriate to assume that cash flows occur in the middle of each time period. For a model based on annual time periods, using a discount rate of 10% and an end year rather than a midyear assumption decreases the present value calculated by 5%. You can work through these problems by making an appropriate adjustment to the NPV function. Alternatively, it is often easier to calculate present values from first principle or use the Excel add-in function XNPV, which allows you to explicitly state the dates on which cash flows occur.

Other functions that often cause errors Lookup and reference functions, such as VLOOKUP, HLOOKUP, INDEX, and MATCH, are susceptible to misuse, particularly when they return what may seem like an appropriate lookup instead of an error. This generally occurs when the range of the lookup reference is smaller than the true range, which means the lookup is working on a subset of the data. To avoid such mishaps, it is simpler to use a defined name (range name) to the data being referenced. That way, all the modeler needs to make sure is that they call the correct range name. Using complex IF statements is a common issue for testing. The problem is magnified if there are embedded IF statements, which are notoriously difficult to decipher. Even when they have been detected, simplifying the formula is time-consuming. Therefore, always test IF statements while they are being created. Even though there is a limit to how many IF statements (seven) can be embedded, still be sure to work well below this limit. If you are finding that you are using all seven IF statements in one formula, carefully consider your modeling technique as this is a clear sign of excessive complicated formula use. Although these functions are often very useful, make sure that you understand exactly how they work before using them in your model. By making the formulas in your model easy to understand, you reduce the risk of introducing errors and increase the chances that a tester will find your mistakes.

The test file Testing is concerned with increasing confidence about the reliability of the model’s results, so it is important that the testing process itself inspires confidence. A well-documented testing process will do just that. A test file is a useful document to illustrate how the model was tested and demonstrates that reasonable steps were taken to establish the accuracy of the model.

285

286

Chapter 13 | Model Stress Testing A test file should contain a record of the different tests that were carried out, such as annotated printouts of the model output and formula maps. The test file should also include an auditable trail of the errors found and corrections made and any other supporting documentation, such as the results of independent numerical tests.

Change requests An important part of the test documentation is a record of the changes recommended in the model and how they were implemented. The tester completes the first section, which includes a description of the error found and, if appropriate, a suggested correction. The description should contain sufficient information for the modeler to correct most errors without having to spend time redoing the original test. The model builder takes the completed forms and makes the required changes, completing the second part of the form. I do not recommend that the tester make the changes to the model for the following reasons: ··

The model builder usually understands the detail to the model better than anyone else. Change requests are sometimes the result from a misunderstanding by the tester rather than an actual error.

··

When more than one person is working with the model at one time, it is important that a single copy is kept as the master version. The model builder can continue to work on the master version while testing is underway.

The third part of the form should be completed by the tester to check that the change has been made appropriately. Retesting changes is important because changes to a model, incorrectly made, can have knock-on effects in other parts of the model. When going through the testing process, using a different version number for each batch of model changes will allow you to keep track of the effect of each correction. It will also make the test file clearer and the process easier to understand. It can also be useful to classify requests on the change request form depending upon their importance: ··

High priority for errors that materially change the results produced by the model

··

Medium priority for errors that have a very small effect or may affect the results in the future

The Handbook of Financial Modeling ··

Low priority for changes that are recommended to make the model easier to understand, but will not affect the results quoted

When time is limited, the builder can concentrate on high and medium priority changes and turn to low priority changes when time permits.

Points to keep in mind when testing The role of testing in modeling is not always appreciated, and it is important to ensure that models do get tested. The following points should be on your mind when building models: ··

Testing can reduce the risk of significant errors appearing in your model results and build up the credibility and influence of the finished model.

··

Errors discovered after the model has been put into use undermine the credibility of the modeler.

··

Testing should always be done by someone other than the model builder, someone who is motivated to find mistakes in the model.

··

If the model builder uses only one unique formula per row or column, it is much easier to test all the formulas in the model.

··

Documenting the test process will help to build confidence in the finished model’s results.

287

CHAPTER

14 Model Audit and Review This chapter examines some essentials to modeling that are actually not in the hands of the modeler, namely, the testing and model audits. Both model testing and model audits are broadly referred to as model reviews or peer reviews. Ironically, model reviews are not performed by the modeler who has created the model. They are instead the domain of an independent person or body. Although it may seem odd that I am including this chapter, I would urge anyone who is serious about modeling to give attention to it. As a modeler, you should have a basic knowledge and appreciation of how testing and auditing are conducted. Not only will it have a positive influence on how you model by allowing you to look from the external perspective of the model, it’s also quite conceivable that at some time, you may be asked to be a reviewer. I would hasten to mention that model auditing has become a well-recognized business activity, and there are numerous organizations worldwide that provide model audits, the “big four” professional service firms—KPMG, Ernst & Young, PwC, and Deloitte—among them. Model testing is far from being an established business practice, so the options are not as clear, although there are a few software applications that work well. In some industry sectors, model audits are not an option. In fact, there is clearly a move to make audits mandatory at some level. In the United Kingdom, for instance, private-public projects are required to have their models audited as part of the tendering process. With aspects like bank risk management, approaches such as Basel III model audit are a fundamental part of the approach. © Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6_14

290

Chapter 14 | Model Audit and Review In summary, a model that has not been audited is a potential liability, and a model that has been audited but not tested lacks guarantees.

How to perform a model audit You will find that the terms “model audit” and “model review” are used interchangeably. Keep in mind that it’s become more likely that large corporations will prefer the term “model review” in order to avoid the implication that a statutory audit has been performed with the same levels of due diligence and therefore possibly raise issues about liability. For the purposes of this book, I will use the term “model audit.” In my opinion, this term more accurately describes what exactly what is happening, whereas a review seems to imply something with less rigor and control.

The process Model audits tend to be one of the last procedures of modeling, usually because there are other activities that are required, prior to an audit commencing, that just seem better left to the end. However, a model audit can commence at any time there is a physical model available and does not need to start at the final model. The general procedure of auditing a model is as follows: ·· A familiarization activity of the model structure begins this process with an added focus on the worksheets and the linking of the worksheets. ·· A cell-by-cell inspection is almost always used as it is the only sure method of systematically discovering errors. The audit will employ proprietary software that will help with this approach. ·· Model errors are fed back to the modeler for correction by using a simple error management system. Model audits can generate a considerable amount of data during inspection, and it’s not unheard for the audit file to be more than 100 megabytes in size. This is the equivalent to 50,000 letter-size pages of text. The time taken to perform a model audit can range from a matter of days to weeks with few hundred man-hours. I have come across many instances where it’s been claimed that model audits are an excuse for modelers to charge high fees to the client for very little work. Don’t let yourself buy into this opinion. If you are given the chance to perform a model audit, you will quickly understand how much effort and painstaking time are required to audit. The fees should reflect this process because it’s well worth the money.

The Handbook of Financial Modeling Following the low-level review that will have established the correctness of the detailed model formulas and other model parts, a high-level review takes place. During the high-level review, wider issues such as the correct handling of accounting and financial issues (i.e., inflation, taxation, depreciation, interest, and margins) are checked. Once the model is correct, it can then be used to investigate sensitivities. For example, a few key model variables—interest rates, cost, and revenue assumptions—could be changed to review the characteristics of the transaction under various commercial scenarios. The performance of the model under these scenarios is checked and documented. After numerous feedback iterations with the model developer have taken place to correct errors and with financial closure invariably pressing, a report is then issued to the client. This report will confirm that various previously agreed review procedures have been performed on the model. Any unresolved issues are documented.

The low-level review A low-level review looks at the logical and structural makeup of the model. This is a very detailed inspection and very slow process with large or complex models. Fortunately, there are a small number of model audit software tools like OAK, Rainbow analyst, and Spreadsheet Advantage that are able to determine the likelihood and severity of error in client spreadsheets and the likely location of errors. One caveat to keep in mind is irrespective of the software, nothing can replace individual cell and row inspection for a complete workbook, which is very incredibly labor intensive. There is also a suggestion that eventually content management software will be developed sufficiently to provide Excel model developers a platform where all the best practices are embedded into every workbook, which could make model audits somewhat redundant. Different aspects will infer information about the relative ease or difficulty and the time needed to review a given model. These include the length of the formula, the ratio of original to repeated cells, the number of cell precedents and dependents, and the locality cell linkages. The tools also produce model maps of a worksheet where the contents of each cell are coded based on whether they have formulas or labels using colors and test labels, such as “F” when there is a formula. These maps allow the reviewer to quickly assess if the worksheet is following best practice modeling rules in relation to formula construction.

291

292

Chapter 14 | Model Audit and Review During the process of examining the formulas in a spreadsheet, the following issues should be considered: ·· Cell references should be valid and not redundant, particularly to highlight any pointing issues. ·· The correct use of functions and its arguments in the formula are needed. ·· There should be no technical errors present, such as #ERR or #REF. ·· No circularities should be present. ·· No hard-coded constants should be in the formulas. ·· There should be a consistent use of the units of weight and measure. ·· Absolute and relative cell addresses should be understood by the modeler. ·· Models with VBA code need checking. This is performed by printing out, inspecting, running, and testing all executable entities. This part of the process of reviewing a spreadsheet is directly comparable with the code review phase of traditional software.

The high-level review Immediately following the low-level review, the next step would be to execute a high-level review. This review would check aspects of the overall integrity of the model that may have been missed by the low-level review. This type of review will generally address the consistency of the model with any supporting documentation. It will also include checks to ensure that finance and accounting issues have been dealt with correctly. For instance, does the revenue recognition conform with IFRS standards, or does the model adhere to GAAP (generally accepted accounting principles)? A high-level review will also check to see if the jurisdiction is catered for within the model. In some instances, the model audit will also address commercial issues relevant to the project that is being modeled. However, this will depend on the engagement agreement between the client and the model auditor.

The Handbook of Financial Modeling Some of the typical steps that will be taken in a high-level review include the following: ·· Make sure that the balance sheet balances, which surprisingly is quite a problem in models. ·· Look at whether retained earnings flow from the profit and loss account to the balance sheet. This is particularly key to how the calculations for the outputs have been designed. ·· Ensure that fixed assets do not depreciate below zero. This may sound obvious, but it does happen if the controls in the formula have been formed incorrectly. ·· Examine how taxation is treated, and ensure that taxes and deferred taxes are handled correctly. High-level checks on the model and its documentation will certainly include a detailed review of the terms of any debt and other funding to ensure that the precise details of the debt provisions are reflected in the model. The high-level review comes with its own control. Any changes to the model during this stage will cause another low-level test to be performed.

Sensitivities Following both the low-level and high-level reviews and the finalization, the model will now be running to specification and is therefore correct. At this point, you can run sensitivities on the model by playing with some key cost and revenue variables, dates, rates (interest, tax, or inflation), discount rates, and debt/equity ratios. For a large model, running sensitivities can be timeconsuming, particularly if the model has not been designed logically. However, in a properly built model, these sensitivities should not cause much of time hindrance. Should any errors be found at this late stage, the model auditors will request a rapid correction from the modeler, and a new cleaned version will need to be produced within days.

Final review report The concluding part of a model audit is a drawing together of all the work that has been performed on the model. A package of documentation will be assembled, which can be used to demonstrate that every check that was required was performed. Any final queries regarding model performance will be cleared if possible. Any areas of concern that remain will be clearly documented.

293

294

Chapter 14 | Model Audit and Review The wording of the final audit report could be stated this way: “the agreedupon procedures have been performed” or “the model is free of material error.” You could also state that the audit provides assurance that all errors are no longer present in the model. Care is taken in final reports to identify exactly which model was the subject of the audit. Typical identification data will include basic information, such as the file name, date, time, and size. The limit to the contractual liability of the firm performing the model audit work is an important issue. A liability figure is always agreed upon prior to any work taking place and is often restated in the final report. In some cases, liability is (or has to be) unlimited, placing onerous responsibilities upon firms and individuals who perform this work on large transactions.

Final say A model audit is a detailed, time-consuming process that is about ensuring all parties involved that they can rely upon the integrity of the model’s financial outputs. Although the practice of including model audits is growing and is now considerably more widely applied than in the early 2000s, it is still not as prevalent as it could or should be. There are literally hundreds of financial models produced each month around the world, but the vast majority will never have any model audit. Let me clear that not all Excel spreadsheets need a model audit; however, every financial model should have some degree of model audit. The seven most common issues typically found in models during audits are ·· Incorrect range formulas ·· Typing errors ·· External sources out of date ·· Copied formula that lead to errors ·· Incorrect negative numbers ·· Incorrect inputs ·· Error messages not fixed

The Handbook of Financial Modeling

CASE STUDY: NEVER ASSUME PERFECTION This case study is based on an incident involving the financial models for an outsource bid in the United Kingdom. It shows why it is important for everyone involved in building models to never assume things are perfect or correct without applying stringent testing and audit.

The background The West Coast Main Line (WCML) is one of the busiest train lines in western Europe and runs from greater London through the Midlands area, then to the north of England, and up into central Scotland with a core track length of 640 kilometers. The WCML is one of the most highly visible and important passenger routes in the United Kingdom, connecting the major cities of London, Birmingham, Manchester, Liverpool, Glasgow, and Edinburgh. More than 23 million people use this train line (the total population of the United Kingdom in the 2011 national census was 63.2 million). In 2011, the UK government concluded a review of the franchise for the line by opening up the competition for the track going forward. This commenced in a detailed bidding process by a number of franchisees, which included the incumbent, Virgin Trains. The corporation that eventually won the bid was called FirstGroup and narrowly outbid Virgin Trains in August 2012. FirstGroup was awarded a 15-year deal to run the line worth £13 billion (just under $20 billion in 2012 US dollars). Unfortunately, the bid process did not go smoothly, and a legal challenge then ensued between the government and the losing bidder, Virgin Trains. Virgin Trains was successful in that legal challenge, proving that the government bid process was flawed. The upshot of this bungled process was a loss to the UK taxpayer in excess of $200 million in legal costs. The most controversial aspect has been that FirstGroup was actually stripped of the contract, which was then given back to Virgin Trains. On all accounts, Virgin Trains, the incumbent operator before the bid, even though they lost out to FirstGroup, continued run the rail franchise until December 2019 when it was taken over by a new operator. So why should this have happened?

The models On August 15, 2012, the UK government announced that FirstGroup had won the bid to run the WCML and would take over running the line from Virgin Trains at the beginning of December 2012.

295

296

Chapter 14 | Model Audit and Review At £5.5 billion, FirstGroup had offered considerably more money for the 15-year contract, as well as offering to pay much more in compensation should the firm prove unable to fulfill its obligations. Soon after the announcement, Virgin Trains immediately called into question the UK government’s decision, arguing that FirstGroup’s bid simply did not stack up. The company argued that the franchise would be at risk as FirstGroup was never likely to achieve any of the assurances they were giving on costs, savings, and compensation. Virgin Trains was so convinced that there was something wrong that they began legal proceedings against the Department of Transport that very month to challenge its decision. Virgin Trains’ legal basis was that the revenue projections of FirstGroup were too wildly optimistic. The company pointed out that these projections were based on passenger growth on the train line of 6% per annum, which was unlikely given that Virgin Trains had seen growth of 5% a year from a much lower base passenger base. Because Virgin Trains had already been operating the line, their predictions were based on fact rather than assumptions. As a result of this 6% passenger growth, FirstGroup’s revenue from the franchise would grow by more than 10% a year, which Virgin Trains found entirely unpalatable and unrealistic. Once these issues were raised by Virgin, there appeared to be a number of commentators who agreed. Very quickly, the suspicion of wrongdoing or mistakes being made by the Department of Transport started to become the focus. What was at issue here was that the revenue targets projected by FirstGroup could not be met. Then, as a result, the company wouldn’t have the money to pay the government the promised fee for the contract, which in FirstGroup’s case was backloaded toward the end of the 15-year term. That risk of nonpayment by FirstGroup would result in the taxpayers having to step in and cover the shortfall of money, which on such a large deal could run into billions of cash.

What went wrong? For starters, the departments that were evaluating the bidders were using an entirely new financial model that was untried in commercially. This model was given to the bidders by the Department of Transport in order to create their bid. But because of issues in the modeling, the model took a very optimistic view to financial forecasts. In essence, the outputs from the model had no inherent error checks, or if there were error checks, they were incorrectly implemented, because the model did not register that the inflation had been excluded from the financial results. What is not clear is if the model ever went through model audit and if so, when and who conducted it? Given that no model audit firm was ever prosecuted or cited for erroneous auditing, it’s very likely that the model was never tested and never received a model audit.

The Handbook of Financial Modeling There were also several suggestions that the model was far too complex and documentation too light. Therefore, the bidders were left in a situation where they managed to input key numbers incorrectly. It is also unclear why the revenue forecasts and the capital that would be required to compensate the taxpayer were not flagged as potential risk. It is clear the risk was not even considered, because that is why there was such a low compensation amount offered ($400 million) when in fact there was a real risk it could be billions of dollars, hence the low calculation for the capital. In this case study, the Department of Transport overestimated its modeling capability and failed to take on board the clear message that models have errors and those errors have to be caught and a solution provided. Again, their failure to do so implies that neither an audit nor testing was deemed to be necessary, a very expensive mistake that is costing the UK taxpayer. In addition, the senior modeler and a number of the modeling team members lost their jobs as well. This case proves that, when modeling, never assume perfection.

297

CHAPTER

15 The Role of VBA in Financial Models Within financial modeling circles, there has been a battle concerning the role that Visual Basic for Applications (VBA as it’s commonly known) and the part it should play in the financial modeling life cycle. Every financial modeler will have an opinion about using VBA with two distinct camps: those who advocate the use of VBA and those who believe VBA does not have a place in financial models. Those new to financial modeling may be curious why such a divide exists, so let’s first take a look at the foundation of VBA to understand its meaning today as a programming language.

What is VBA? Visual Basic is a high-level programming language which allows developers to produce code irrespective of the type of computer being used. The syntax or language used to code in VBA is akin to the English language.

© Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6_15

300

Chapter 15 | The Role of VBA in Financial Models The opposite of a high-level language is a low-level programming language. This low-level language uses an abstraction that is closer to a computer’s natural processing method and is therefore more compact, faster, and more efficient than a high-level language. Low-level programming language is incredibly difficult to master, and it does port to different computing environments easily. The main use of low-level language is for programming device drivers, embedded systems, and computer gaming. The most untainted low-level programming language is called assembly (sometimes referred to as machine code) which uses binary machine code instructions which are incredibly difficult for a human brain to remember or even to write down because they are not interpretable into human language. High-level programming languages use an interpreter to convert them into something that a computer will understand and are therefore closer to human language. If you have come across mention of C++, R, Python, Visual Basic, Perl, and COBOL among hundreds, then these are high-level languages. VBA is a version of a larger Visual Basic suite (VBS), the difference being VBA is embedded within Microsoft’s products like Excel, Access, Word, Visio, and PowerPoint. In the hands of a competent developer, VBA is very powerful, and despite it being a derivative of the VBS, it is actually a complete environment in its own right. Microsoft wanted a coding tool to appeal to a wider audience, so they made VBA accessible to everyone free of charge as long as you had one of its applications. They created an environment that simplified the use of code, even going as far as having a VBA macro recorder which creates code on the fly by watching and recording the application user’s behaviors and movements. There was a problem looming that even Microsoft had not intended. Because much of the VBA code written today is created by people who have little or no appreciation for computer programming conventions, the quality of VBA macros developed in Excel is really quite poor. What this means is so much of VBA code is actually incomplete and very limited in functionality. People are writing VBA code in financial models that will only perform under very specific and limited conditions; should anything slightly change, then there is no robust coding built in to deal with the change and the VBA macro crashes. There is nothing more irritating and damaging than having a financial model crash with no explanation or self-recovery mechanism. Such are VBA crashes that once they occur, it’s incredibly difficult to roll back to where you were and start again. Generally, there is nothing one can do but shut down the model and start again, or even throw the model away.

The Handbook of Financial Modeling This is the reason why some modelers and, in fact, many people have an aversion to using VBA in financial models. The premise is that financial modelers are not computer developers and therefore cannot adequately code in VBA.

 sing Visual Basic for Applications U (VBA) in financial models This section is intended to take you through the basic steps of using the Visual Basic Editor (VBE) window and writing a simple piece of Visual Basic for Applications (VBA) code. It will show you how to use the VBE, the project explorer, and code windows. You will learn how to write a simple macro to display a “Welcome to Modelers World” message box.

The Visual Basic Editor (VBE) in Excel For the majority of Excel users, their first and only brush with VBA is with using the macro recording by clicking the Developer tab and clicking the Record Macro button. It’s quite possible that most of these users are unaware that aside from being a spreadsheet application, Excel happens to also be a powerful programming language development platform that is capable of even building applications. You can use VBA code to create macros that can automate tasks in models and moreover give the model a more polished feel. A macro is a procedure written in VBA code that performs definite tasks such as flashing a message on the screen for a specific number of seconds. Excel’s VBA is a complete object-oriented language hidden in VBA projects that are stored and saved within the workbook. Object-orientated programming languages such as VBA or C++ use object structures and hierarchies, and you can even create your own objects. There is a continuing debate as to whether VBA has a place in financial models or not. Some believe that models should not contain VBA and that VBA in models runs contrary to best practice. In some ways, I can understand why some would have this view. It comes from the experience that many have had with VBA, which is often that someone creates some elegant VBA macro that provides all kinds of solutions and then that person leaves the organization. In time, the spreadsheet with the fancy VBA becomes outdated, and the VBA starts to crash and go wrong. Because no one around has VBA programming experience, the file gets trashed under a cloud. To some, VBA in models has overtones of this situation.

301

302

Chapter 15 | The Role of VBA in Financial Models However, I am one who does not subscribe to the notion that VBA should not be in models. In fact, I am very much for it. The question any modeler should first ask is this: can any tasks be performed efficiently without VBA? If so, then do it. But if a task is significantly better performed using VBA, why not do it? The challenge is that in order to make sure models don’t contain bad VBA, the onus is on modelers to step up to the plate and become accomplished at VBA. If you are a modeler and have an aversion to VBA or are weak in it, then you must not put VBA code into your models until you have become accomplished. The opposite is also true. If you are a modeler who has good working experience of VBA, why not use it in moderation? I use VBA to automate tasks and to assist me with the model building, and then I pull the VBA out of the final model. But now and again, I will include it in the final model. Typically, I use VBA for the following tasks: ·· To give a message to the user such as a confidentiality warning or a message to let the user know the status of the model when it is opened ·· To perform an internal audit of the model data automatically ·· To make a log of the model users with times and dates and to note any changes that were made ·· To lock the model so that it cannot be saved as another file name ·· To make sure the model always opens on a particular worksheet, irrespective of where it was closed ·· To make issue logs for maintenance that are sent directly to the maintainer ·· To make printable copies of the outputs and any other data

Basic understanding of VBA Let’s start by finding where VBA macros are stored. Macros are kept inside hidden VBA projects that are stored and saved within the workbook. VBA projects can be accessed through the VBE by pressing Alt+F11 to see the window shown in Figure 15-1.

The Handbook of Financial Modeling

Figure 15-1.  The VBA editor in Excel is accessed by using the combination of the Alt+F11 keys

The editor window contains menus for File, Edit, View, Insert, Format, Debug, Run, Tools, Add-ins, Window, and Help and opens in a separate window, so there should be no fear of losing any work you have done in your worksheet. Working with the VBA editor requires a subtle change within the mindset as you need to think very logically about what you want to achieve but also at the same time what you don’t want to achieve. Think of it like this: thus far, you have been working with Excel worksheets. Now, imagine that each worksheet is a room in a house full of all kinds of objects. Once the VBA editor is opened, which brings up a project window explorer, we can open the doors to all those rooms to the house, and each room has several objects in it. The VBA editor allows you to select the room you wish to look at and then further select an object and adjust or tune that object (called properties) according to your preferences at a detailed level.

303

304

Chapter 15 | The Role of VBA in Financial Models

Coding in VBA for modelers This section will introduce the VBA project and take you through writing some VBA code.

VBA project explorer and code windows The VBE project explorer shows a project tree on the left-hand side of the screen below the menu and toolbar. If you click a branch of the tree, you’ll enter that particular workbook or worksheet from the VBE. The VBA project is the root of the tree, and the workbook and worksheet objects are the branches coming off the tree. As you add and delete worksheets or workbooks, the branches of the tree change to reflect the new worksheets or workbooks being created. Therefore, what you can now see is a list of currently loaded workbooks and the worksheets within an explorer. I mentioned earlier that VBA is an object-orientated language, which means everything in the explorer is an object including the workbooks and worksheets. There are some introductory steps to using the editor that I will go through to help you become familiar with the editor. This is by no means a tutorial on coding in VBA, and indeed I would recommend that you invest in a good introductory VBA guide such as Excel VBA Programming for Dummies (fourth edition) by John Walkenbach or Excel Macros by David Williams. Your first point of call is to double-click ThisWorkbook in the left project pane. The workbook object opens in the right pane, which is blank in Figure 15-2.

The Handbook of Financial Modeling

Figure 15-2.  ThisWorkbook is now activated, and a blank editing sheet is open on the right

If you try and type something into the blank space, you will get a message box informing you that there is a compile error similar to that in Figure 15-3.

305

306

Chapter 15 | The Role of VBA in Financial Models

Figure 15-3.  There is a compile error because the message written has been recognized and does not conform to VBA coding structures

This error is like a guide. When working with VBA Messages like Figure 15-3 will soon become familiar, because like any programming language VBA implies upon the user several strict structures. This error has occurred because you have typed in some arbitrary natural language and haven’t followed the rules about how to enter VBA code. Behind this seemingly innocuous blank sheet is a system called a compiler, which you can think of as an interpreter. The compiler takes written messages that are typed into the editor and converts them into instructions that your computer can then understand and thus execute. Close the error message and delete the message that caused it to appear. Then, click the drop-down list in the top left corner of the blank sheet with the word “General” as per Figure 15-4.

Figure 15-4.  The general drop-down is the starting point for placing the VBA code

The Handbook of Financial Modeling Using the drop-down, choose the option for “workbook.” You will then see that there has been an automatic placement of some code into the blank sheet, as shown in Figure 15-5.

Figure 15-5.  The VBE has automatically placed the workbook Open subroutine as the starting point

This is called subroutine, and specifically, it is an event. VBA has several types of events, which you should think of in exactly the same way as we use the term “event” in common language. It is an observable occurrence or a phenomenon. The event that has been automatically selected for us by clicking workbook from the drop-down is the Open event on the workbook. Therefore, the editor is expecting some code to be placed between the starting lines and the ending lines. Once you’ve added the correct code, the editor will execute the subroutine when the workbook is opened. If at this point you are unclear with the process, go back over these last few paragraphs. This event is one of the most applied types of coding that is used in modeling. Here is another point to understand before I go any further. I mentioned that there are a number of events available to use. On the top right of the window, click the Open drop-down, and there will be a list of many event types called declarations, as shown in Figure 15-6.

307

308

Chapter 15 | The Role of VBA in Financial Models

Figure 15-6.  The drop-down list in the VBE has a list of events

It’s important to note that although the editor always places the Open event automatically, you don’t have to stay with this event—you can choose any event that is on that list. In order to do so, just delete the Open event and click the event you require in the declaration list shown in Figure 15-6. I do have a note of caution. When you delete any events that you do not want to write code against, make sure both the starting line and the last line that has End Sub are deleted. A common mistake is to leave partial code in the code window while the other part is deleted, and therefore, you end up with a subroutine that is missing its pair and becomes delinquent. This mistake will cause an error once the code is executed, and believe me, this type of error is extremely frustrating. It has to be checked manually and can be very difficult to spot, particularly when there are hundreds of lines of code. Consider yourself warned. Now, I will instruct you on how to create a simple macro with some VBA code. With the Open event displayed, click the declaration list drop-down, and directly above the Open event, click the NewSheet event. An event will be placed in the editor above the Open event, which should look like Figure 15-7.

The Handbook of Financial Modeling

Figure 15-7.  The MsgBox defined text is used to generate a message box

Type the following into the NewSheet event between the first and last lines: MsgBox “Welcome to Modelers World.” In this instance, I have asked you to use a defined code word called MsgBox, which in VBA will call up a message box (you can see how the code language is not far removed from English language but still has some way to go before it’s completely intuitive). But when using a defined code word such as the MsgBox, you need to stick to the syntax of the language exactly. So, in this instance, don’t be tempted to change the case to the code, such as MSGBOX. It should remain as lowercase. Otherwise, it will cause a compile error. In many instances, the editor will recognize which defined word you are trying to enact and correct it by using a predictive algorithm. However, do not rely on this because often it will predict something different than what you want. Note also that once you have placed the punctuation marks after MsgBox, you can insert whatever you wish in between them. Figure  15-8 should resemble what you have in the editor to this point.

309

310

Chapter 15 | The Role of VBA in Financial Models

Figure 15-8.  The MsgBox defined text is used to generate a message box

The MsgBox code is the one I use in some of my models, as it’s a very potent method of imparting information about the model based on a particular event occurring. For example, when a model is opened, you can provide a disclaimer message or share a warning to the user. While it’s possible to make fairly sophisticated message boxes, I am not sure that plays well in models. It’s always a good idea to avoid creating overly complex code when something simpler can be just as effective. I would advise that you stay with simple message boxes, which are sufficient. You may have noticed that after you type in the word MsgBox, a box containing all the parameters for this defined word command is displayed. This can be useful in informing you about which parameters are required and what order is required for that function. A concern that I have come across from modelers with VBA code is how to use it in the actual worksheets of the model. There are different ways to accomplish this task by using controls such as buttons, links, or automated functions. To see the code run, return to Excel, right-click the sheet name (for instance, Sheet1), and then click Insert, which will insert a new sheet and execute the NewSheet event you just defined (see Figure 15-9).

The Handbook of Financial Modeling

Figure 15-9.  The “Modelers World” message box can be seen running from your VBA code

Again, keep in mind that this is just an introduction to VBA. You will need to develop what you have read here further, but if you found this difficult and challenging, you should take heart that as a modeler, you do not have to be a VBA expert. In fact, VBA is not the be-all and end-all of modeling. But sometimes VBA is necessary, and you need to be comfortable with using it. Your understanding of VBA should be at a level where you can write viable code. The good news is that even coming from a point of never having seen VBA before, you should be able to become reasonably accomplished within months (rather than years) for modeling. Hang in there and give it your best shot.

Case study: how VBA benefits models VBA has often been the focus of contention in financial modeling. The issue is whether financial models should incorporate VBA or not, and opinions vary depending on whom you ask. The reasons for and against VBA can be just as varied, but ultimately, they all lead to the robustness of the coding. There can be no worse situation than taking possession of a model that seems to function appropriately, only to then have an error message appear out of the blue that halts the model’s operations and has little or no explanation and no help as to how to rectify the problem. Unfortunately, this is an experience many users of financial models that have VBA have come across, and it has tainted their appreciation for VBA. The alternative is to build a model that has no VBA code at all.

311

312

Chapter 15 | The Role of VBA in Financial Models So, where do I stand? VBA is integral to modeling, and by dismissing it, all that happens is that we diminish the creativity and possibilities available to the modeler.

Why is VBA good for modeling? There are a number of reasons why VBA is good for modeling, and on the whole, VBA can bring more good things than bad things. These next few sections will describe the advantages with VBA.

Reduces manual time With some careful thought and application, it is very possible to create VBA tools and routines that cut out much of the manual time when building models. I have created VBA routines that can analyze data and then pull out specific information I request and populate a table with it. Or the tool can check through an entire model and look for redundant formulas (formulas that lead to nowhere). Creating these routines is very quick; the hard part is just understanding what it is that you want.

Provides quicker processing times The truth is when used correctly VBA is fast. In fact, it’s hundreds of times faster at processing large quantities of information than pure formulas. Often, I have been shown a model by a customer that has VBA code, and unfortunately the VBA seems to have slowed down the whole functionality of the model. On closer inspection, it’s obvious why. I find that modelers of Excel users who are not totally proficient at VBA will sometimes make the mistake of creating code that reads and acts on information in the worksheet cells. Then, when there is a large data set, the code will run the subroutine of every single cell. As a result, this cycle will cause the VBA to run slowly, and it’s not the best way to code. In fact, code should be created to work within the code itself.

Utilizes events This is not a well-understood point but let me explain. When modeling, the modeler should always have an eye squarely fixed on the user’s experience. Modelers should be thinking how the user can use and get the best out of the model. With this viewpoint, modelers should be anticipating not only what the users are going to do but also what they are capable of doing, and this is often not clear.

The Handbook of Financial Modeling By using VBA judicially, it is possible to build code that can look for specific events that occur and provide guidance to the user. For instance, what happens if the user makes input changes to the model and closes it without saving? Believe me, this is possible. It’s also possible to create VBA code that will always create a backup copy whenever there have been changes made to models. So, in this case, the VBA code will execute in the event that a change is made.

Enhances the model user’s experience There are several aspects to modeling that could be enhanced, and often the only way is by using VBA. In some of the very large models that I have created, I have provided a context-sensitive help system. For example, when users are viewing a balance sheet, they can receive information about financial statements. There is also an automated self-audit. This means that when the model is closed, a specific VBA code will run and check the status of the model and make a record of the inputs and the results of the outputs based on those inputs and will then place this information in an archive for audit. This is useful for model maintenance because if something goes wrong with the model, it’s possible to check its status before the issue happened. There can be a little doubt that VBA can benefit modeling. The question should not be how VBA can benefit modeling, but more about establishing best practice guidelines that will ensure that VBA in models adheres to a set of principles, which will benefit models and the user.

313

CHAPTER

16 Operis A case study In each of the previous chapters, we looked at the elements that make up the broader toolset of a financial modeler. You will notice as you get to this chapter that financial modelers don’t have a predefined background and they come from all walks of life; however, we are about to discover in spite of the varied background that there are some underlying common traits that ensure success as a financial modeler. At some point in time, you will be asked to explain what you do as a financial modeler and also to explain to someone what a financial modeler is. Like me, you will likely realize that trying to define modeling and explain it to someone with no prior knowledge is difficult because so much about financial modeling is down to how someone has been trained and developed. You see what makes a financial modeler is not what you do, it’s how you do it. In this chapter, I want to provide a case study of a real living and breathing international company who by all accounts has for the past 30 years been developing and nurturing world-class financial modelers. By putting forward this case study, you will hopefully be able to get some context to broader activities and services companies perform and how modeling is used in providing such services.

© Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6_16

316

Chapter 16 | Operis

Introducing Operis Operis is a UK company formed in 1990 by David Colver and Hugh Daniel in London. The company supports clients in the private sector across the globe who are seeking finance for infrastructure and energy projects. Operis has its origins in the financial modelling and model auditing of project finance transactions. (You will notice that as we are case studying an English firm, I use “modelling” as opposed to “modeling” for this chapter). In the 30 years since being formed, Operis has grown into an international firm, executing more than 3,000 assignments, 60% of which are international (outside of mainland United Kingdom; see Figure  16-1). Over that time, Operis’s activities have widened to include

Figure 16-1.  Operis assignments are from across the globe

The Handbook of Financial Modeling Financial advice: By guiding sponsors and investors in sourcing, structuring, and negotiating funding for public-private projects and broader project finance Model development: Building financial models and using them to deliver analysis to project promoters and asset owners Model audit: Validating financial models produced by third parties on behalf of funders and investors Tax and accounting services: Providing advice, opinions, and due diligence on tax accounting treatment for bids and other transactions In addition, Operis is a provider of leading world-class financial modelling training to organizations and individuals and is also the developer of the OAK software, a leading financial modelling software tool.

How Operis structures its work teams The Operis team is structured so that all consulting work, whether modelling, auditing, or advisory, is delivered by the same analytical team and led by senior individuals, including those, on the financial advisory side, with investment banking and fund management experience. Each individual has exposure to a large number of projects and can take skills and experience from one discipline and apply those to the other streams of business. The members of their highly skilled and respected team have strong analytical backgrounds gained in engineering, mathematics, and physical sciences, are all trained in-house, and have dedicated modelling careers, which enable them to review and develop complex financial models. Assignments can also be supported by qualified tax and accounting specialists to provide tax and accounting advice on a transaction. Work is carried out exclusively from the offices in London and Toronto, not outsourced or performed remotely by an offshore team. This configuration gives Operis clients a joined-up experience while also internally ensuring a consistent high-quality service to clients. Financial modelling is Operis’s bedrock, which is valued highly at the core of their organization.

Operis and financial modelling teams’ careers Operis recruits financial modelling analysts from universities by selecting those who have demonstrated outstanding success academically and in maturity. The entry path into the company for those selected is as an analyst, who are nurtured through the Operis training and developed within the team structures. By the time analysts are ready to continue on their career path,

317

318

Chapter 16 | Operis they will have been exposed to over a dozen international assignments (in financial modelling and model auditing) and projects and would have had exposure to a number of different teams and functions. The consultant is the next step progression from analyst within Operis, with individuals being further nurtured and trained and given further exposure to other teams and specialists. A consultant can then move up the career path to a senior consultant. The Operis senior consultant will typically have been involved in more than 50 international projects and will be technically and commercially fully a world-class modeler. It’s no coincidence the Operis senior consultants are a very small pool of very highly sought-after professionals, who are constantly head-hunted, particularly in the banking sector. The next step from a senior consultant is a manager, who has responsibility for a number of financial modelers and leads modelling assignments. Managers will typically spend less time engaging in day-to-day model builds and reviews; rather, they will oversee modelling and provide guidance. Managers have a significant client engagement role and will spend a portion of their daily activities actively working with clients. It’s also at this stage where managers play a part in business development by responding to new opportunities from clients.

PROFILE OF AN OPERIS SENIOR CONSULTANT We discussed some aspects of financial modelling with a senior consultant at Operis to get insight into modelling for the company. Dominic Waters joined Operis in 2017 as an analyst straight from completing a master’s degree in physics at Durham University in England. You would imagine Dominic could have sown a career in other fields like engineering or research, although it was always his plan to go the financial route. Dominic found that the skills harnessed by taking physics, which has a strong numerical requirement, have been integral to helping him develop through financial modelling with aspects such as a logical approach to problem solving and report writing.

One path to entering a career in financial modelling Interestingly when we asked Dominic whether there would have been more advantage to him entering financial modelling at Operis having taken a financial-based degree like economics or accounting or indeed becoming a professional accountant, it was clear such a route was not necessary. In his words, “Those financials sure will be required in modelling, but they can be learned through taking courses or through job progression, and so don't need to take as degree.” I have to agree with Dominic that pursuing a nonfinancial degree should not be a barrier to becoming a financial modeler, although much depends on the organization that the individual will be joining.

The Handbook of Financial Modeling Operis quite clearly has more pressing priorities which go beyond the degree subject, although if someone does not have a numerate degree, they do want to see a demonstration of significant numeracy in all their potential financial modelers. We asked Dominic to give a summary of one very challenging and complex financial model he built from scratch. The model was a six-year operational model, but what made it challenging were the requirements to implement several detailed cash flows which needed to follow complex legally documented calculation methods. Coupled with several debt seniority calculations and because there was a possibility of IPO in the future, the model had to be robust enough to accommodate an IPO up to six years in the future. This summary of the types of models Dominic has constructed suggest that Operis’s development of their financial modelers is such that these modelers are able to tackle very complex assignments within a relatively short time from entry into the organization. This would lend credit to the training and overall culture of the company that financial modelers in Operis, in less than three years, are able to build highly complex infrastructure models. We challenged Dominic to suggest the critical qualities required for someone in his position going to modelling. These are the qualities or skills Dominic suggested: A head for numbers This is not to suggest that if you don’t have a mathematical degree, financial modelling is off limits; however, it is vital that to be a modeler, numbers should not be a problem. Sense checking The ability to quickly and naturally sense check calculations as they are being created while also knowing where the issue will lie. Dominic explained that if you know the numbers you are working to calculate, then you can quickly understand the magnitude of the result and therefore be able to sense check the result. This will save painful time in the future trying to find errors. Method and thought The natural tendency can be to develop straight into building the model, doing the thinking about structure and presentation later, only to find that time has been wasted because the model is too complex and just not useable for the client. For modelers, they need to quickly develop the understanding and discipline of presentation, method, and simplicity and thought and then display that in the models they build. On final thoughts we asked Dominic if he though Excel was an important tool for a financial modeler to learn prior to embarking on a career. In short, Dominic explained that while Excel is a requirement, it can be learned fairly rapidly for the purpose of modelling and therefore is not a prerequisite skill. Also, more often than not, today’s graduates are already primed with the basics of spreadsheets, which elevates the speed to learn.

319

320

Chapter 16 | Operis I would like to give my thanks to Dominic Waters for giving this book access to his career to date and insights into the development in financial modeling at Operis.

PROFILE OF AN OPERIS MANAGER At Operis, the financial modelling manager is someone who has actively operated on a wide range of international projects, built, audited, and assisted with a great number of financial models. Once an individual achieves the manager level, they will assume greater and wider responsibilities which will see them less involved in the day-today technical build of financial models. The manager will mentor and lead financial modelers, overseeing their progress and managing their career development. We can look at the one such manager Michael Jarman who joined Operis in 2014 coming straight from studying economics at Cambridge University in England.

A typical week for a manager at Operis When asked to explore his involvement with financial models in his present role as a manager, Michael related how a large part of his day-to-day work is interfacing with clients and overseeing the financial modelling aspects of a project. Michael heads up the modelling teams and scopes the modelling assignments and can, at times, get involved with the actual physical modelling by giving assistance to analysts, consultants, and senior consultants. We can see quite clearly that Michael’s position now sees him doing more to represent the company in the outside world and also take on responsibility beyond the physical model by managing resources and the project. At this stage, Michael’s technical modelling skills and experience are high quality, which is demonstrated by the fact that he came third in the international ModelOff modelling competition in 2017 and then went on to win it in 2018.

The personal qualities that make for a good financial modeler So, what is it that makes a successful financial modeler not only at Operis, but generally? Have a logical mind In Michael’s view, the critical qualities for any aspiring modeler are an innate ability to take real-world representations and be able to logicalize them into something that can be easily followed such as a model in Excel. He was quick to dispel the myth that financial modelling is about being an Excel expert; in fact, Michael states, “Excel skills can be learned and taught to anybody, so Excel is not the issue.”

The Handbook of Financial Modeling A natural sense-checking mind The other quality that Michael described for a successful modeler is to be able to naturally apply checking mechanisms into all their models. The modeler should always be foreseeing issues and patterns of behavior that a user of the model may take and building models to guide and check for these patterns. When approached about the role of coding in VBA within models, Michael’s view was that often coding is necessary, but it’s important for financial modelers to understand the implications of coding within models and to build models with code that are critical to the model, rather than being a stage show to demonstrate a modeler’s coding prowess. It was clear that Operis gives their financial modelers a very comprehensive training in coding, but it was up to the individual modeler to then decide when to apply code. What we can see from the profile of Michael is with an organization that has financial modelling at its core, there can be development and growth path for a financial modeler beyond the pure technical modelling.

I would like to give my thanks to Michael Jarman for providing this book with a feel for his weekly activities and giving insight into what development in financial modeling at a leading organization can look like.

PROFILE OF AN OPERIS ASSOCIATE DIRECTOR Associate director sits within the analytical teams and leads the financial modelling assignments and also provides financial modelling in the wider and broader advisory service. Also, associate directors lead on model audits where they will be the sign-off. David Rosel leads projects and is an associate director who joined Operis in 2004 as an analyst, coming in as graduate after he studied mathematics at Cambridge University. David was attracted to Operis because although he wanted to move into a finance career, he also wanted a role that was somewhat real world, quite technical, and had client engagement as opposed to back-office or trading. Operis provided the ideal environment for David with its analyst career path and world-class financial modelling training. David has gone through the Operis financial modeler career path such that as an associate director, he has a formidable experience in just about every aspect of financial modelling. In seeking to get an idea of the typical day-to-day activities of an associate director from David, we observed the following:

321

322

Chapter 16 | Operis Associate directors are not involved in the day-to-day model building or auditing as they have a team they lead, which handles those tasks. In David’s words, “My role is to help out with anything difficult, I should be there to be a sounding board to help out with anything tricky or problems that come out.” ··

The associate director will help and guide their team but will also check the team’s work and ensure results are correct before they are sent out to clients.

··

In terms of work split, David suggested that the split between audit and financial modelling advisory is 50:50.

··

A part of an associate director’s activities is devoted to sales, in terms of developing business opportunities.

Financial modelling and accountancy We asked David to give us a view from his experience about the debate on financial modelling and accountancy being linked. David believes it’s possibly more helpful for someone coming into financial modelling with a blank slate, rather than having already been formed into a professional with specific ethics and rules like accounting. This will help new modelers to learn how to develop financial models in a logical and methodical fashion without having a preprogrammed manner to approach financial model like an accounting assignment. David does say that there are obvious advantages to being an accountant when starting out as a financial modeler. From his experience, he found that he had to get to grips with several concepts in tax and accounting and be aware of the standards which did take some time to really understand. However, in Operis, there are specialists in tax and accounting who will provide the support, so there is no requirement for an analyst to be an accountant.

The personal qualities that make for a good financial modeler Throughout this book, I have pushed an underlying theme to uncover what makes someone a financial modeler. To answer we need to understand what financial modelling is and what it is not. Hopefully by now, you will know all that is financial modelling, and most of the aspects that are not. For instance, a financial modeler is actually an analyst, they are not an Excel developer, nor are they necessarily an accountant. In this case study, I have challenged each of the profiled professionals from Operis to provide their view of the personalities or personal qualities that make for a successful career in financial modeling. David Rosel provided a number of insights into which qualities are not just helpful but critical for financial modelers to have.

The Handbook of Financial Modeling Have a structured mindset A modeler needs to assimilate complex problems and then break them down into simpler components while at the same time being able to not only see, but demonstrate, the effect of these components on an overall problem. David stated that financial models are difficult because maths or the financial structures are complex and the models have a lot of moving parts that interact with each other. The levels and the nature of those interactions and the explanation of subsequent results are complex. A critical quality for any good modeler then is the ability to reproduce, demonstrate, and explain those interactions; in order to do this, the modeler needs to have a structured mindset. Being able to interpret results and explain to clients Another quality that is critical for a financial modeler is the ability to explain the analysis and the results within a financial model to people who will make decisions based on that financial model. In the case of Operis, the clients need to have confidence that financial models are not “black boxes” where information goes in, and results come out, but there are “how” and “why” explanations to the results. David recognized that not all financial modelers are capable of being able to build financial models and also engage with clients as they have different skills, although at Operis, these types of skills impact a financial modeler’s upward career progression. I would like to give my thanks to David Rosel for allowing me to use his deep insights into financial modeling and giving real-world experience in how to shape a career in financial modelling.

Overview and conclusion I based this case study on Operis for a number of reasons, paramount being they have financial modelling at the core of their organization. Operis also closely aligns with the history of financial modelling as they are one of a few core organizations that have been in existence more than 30 years with financial modelling. Operis is foremost an international project finance advisory firm that offers clients a number of services, of which financial modeling and model audits are a part. Where there are infrastructure assignments, then Operis have the organizational structure to take them, in which every industry may be, as seen in Figure 16-2.

323

324

Chapter 16 | Operis

Figure 16-2.  Operis operates in infrastructure across all sectors

What makes Operis very useful for this case study is that the organizational structure is embedded in individuals who are part of a team and all these teams have access to each other. What this means for profiling in this book is that we can be assured that all the financial modelers whatever their progress or level in the organization are well-rounded and exemplify the company ethos, with few or no anomalies. Simon Williams is the commercial director at Operis and gave insight into the way they work with their new recruits. The company is very aware that all its recruits need to be immersed in learning, and to quote Simon, “They (The recruits) are going to be a sponge, their brains will be pulling in information from all areas, whether it be mentoring or the training that we provide. We also want to make sure these young people meet everyone in the firm at their immediate point of joining, so they will spend time with the Chairman, CEO, Head of Tax Accounting, Head of HR, you name it.” These activities are designed to make sure new recruits become aware of what everyone in the firm is doing, which encourages a team approach and discourages working in silos. This and other approaches to the new recruits are also designed to ensure that analysts understand Operis is a consulting firm, engaged in winning and maintaining clients. Thus, even though Operis recruits the very brightest analysts, the firm is also ensuring these analysts grow to be not only technically world class but are also commercially savvy. Operis will achieve growth in the future and expand internationally. In the words of Simon Williams, “We have a strong appetite for expansion with dedicated offices throughout the world.” This sets the tone for future growth.

CHAPTER

17 Financial Modeling, Where Next? When I wrote the first edition of this book, there were clear signals to how financial modeling will develop in the future, which was seven years ago. Most of those developments have now happened; however, the next decade is increasingly more difficult to foresee where financial modeling will go. What I can comfortably assure you is the need for financial modelers will not diminish. In fact, there will certainly be an increased reliance in commercial business for professional modelers. The question is: how will the financial modeler of tomorrow differ from now? Let’s explore that question.

Future demand for financial modeling The future for financial modeling is certain to be one of an increasing use for modelers and models. This is clearly the case when you look at the history, where, before the turn of the century, financial modeling was still a relatively niche business discipline which was only adopted in sectors of business such as investment banking and public-private funding schemes. However, today

© Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6_17

326

Chapter 17 | Financial Modeling, Where Next? financial modeling is considered in a number of sectors as crucial, and it’s possible to find modeling adopted as a practice in several industries such as utilities, oil and gas, telecommunications, retail banking, business process outsourcing, advisory, and consulting. Further, businesses are awake to the value that good financial modeling can give the ability for an organization to model the effects of varying economic and environmental scenarios on a company’s performance, and cash flows have many potential benefits such as helping to raise funds. A decent financial model infuses confidence among financial institutions, and more often, it is now a requirement to provide banks with robust models when looking to secure financing. Infrastructure projects worldwide will almost certainly increase particularly as central authorities continue to look at what is required for their economies to achieve stability and growth. As we have seen in Chapter 16 with Operis Group PLC, the role that financial modelers can play in such projects is immense. Smart organizations that want to stay ahead and grow their business infrastructure will invariably invest in building their financial modeling resources or will contract out to independent financial modelers. This means that financial modeling will continue to gain usage across business and industry for the future, and I fully expect the use of models to increase at pace as more companies are awake to how useful good modeling can be for their business. The future financial modeler All this increase demand is bound to have an effect on the profile of the financial modeler, and it’s certain there will be fundamental increases in the skill sets of the modeler of the future from that of today. Today, apart from a few forward-thinking organizations such as Operis, financial modelers are focused very much on building one-time usage types of models, and there’s less thought about building standard model tools. However, this will need to change to more uniform and standardized modeling tools because businesses are becoming much more risk-averse. This means financial modelers will need to be more credible. We have seen that organizations like Operis put considerable resources into training and developing their modelers and exposing those modelers to assignments that stretch the skills until they are capable of modeling in all scenarios well. Today, there are still too many organizations that do not understand financial modeling, but believe they need it, and so appoint people to model who are really not financial modelers (although they may believe they are). Most of the organizations I have been involved with in the past since the first edition of this book have spreadsheet experts masquerading as financial modelers because they can do sexy things with Excel. This is not the individuals’ fault; it’s down to the organization and the culture of development internally.

The Handbook of Financial Modeling I fully expect that the financial modeler of the future will be altogether a much more rounded individual than is apparent today. There are increasing demands on modelers to go beyond being just able to build models; there are expectations now that when an organization hires or takes on modeler, they are getting someone who ··

Is capable of applying commercial sense to models

··

Understand and can apply complex financial principles to models and can demonstrate that experience

··

Understands the implications of risk and can model for this

··

Is able to communicate and work with people from various business functions

··

Can manage a project

··

Is able to interpret the results of the models and present these to a wide audience which includes banks, investors, senior staff, and the public.

··

Is bound by some code of ethics, which does not mean they must be an accountant but that they have followed some professional training route in the past

··

Has a strong client or customer engagement experience

··

Is able to apply data analysis skills without much thinking

··

Is conformable with methods and implementing robust coding

Don’t get me wrong, there are modelers today who not only tick all the boxes I have mentioned but also have several more skills that I have not mentioned, but also there are great many modelers who would not be able to tick even half of these, and it’s there where things will change. Don’t be surprised to find financial modeling going through a period of establishing some worldwide accreditation largely based on the organization where they were trained. The increase and the profile of the modeling projects in the future will necessitate that there is some rigor placed on the practitioner.

Evolutions in financial modeling Some of the big developments that must and will come for financial modeling will be in compliance. Many of the leading players who develop tools or software for spreadsheets and modeling are already hotly developing methods that will ensure anyone using their products is compliant with rules and regulations such as IFRS. This aspect will develop further because the repercussions of falling foul of any of these rules are great and generally

327

328

Chapter 17 | Financial Modeling, Where Next? fall on the officers of the organization. I do see an end to the days when modelers can freely create and build around the financial statements in their models without some review or checks; it’s not long before this becomes a problem. The other evolution is around how models are built. There is best practice modeling that is now entrenched; however, there is no one prescribed methodology; instead, there are several differing methods of building models, each with their individual reasons why theirs is the best. However, like software development, which took time to develop its idiosyncratic lifecycle methodology, I am certain modeling will evolve in a similar manner, in that there will be a financial modeling life cycle that will become the ideal and accepted process of how to develop and deliver models to a standard. What is the natural career progression of a financial modeler? We have seen how an organization like Operis had created a progression tree in the consulting realm; however, how does it work generally? Where will those who have spent their formative years building financial models eventually end up in their careers? Will modelers become financial directors, investment directors, commercial directors, strategy directors, or data governance directors? Unfortunately, this part of financial modeling is unclear yet, as there are not enough seasoned financial modelers from the corporate world to evaluate any trends of where they end up, but it’s one to watch in the future. Perhaps, they may even write a book!

APPENDIX

A Modeling Glossary and Terminology Income statement terms The following is a list of terms and their definitions that are used in income statements. Term

Detail

Cost of goods sold

For a retail or wholesale business, it is the total price paid for the products sold plus the cost of having them delivered to the store during the accounting period. For a manufacturing firm, it is the beginning inventory plus purchases, delivery costs, material, labor, and overhead minus the ending inventory.

Gross profit

This is the amount before operating expenses and federal taxes have been deducted.

Income before taxes

This is the operating income plus other incomes.

(continued) © Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6

330

Appendix A | Modeling Glossary and Terminology

Term

Detail

Net income

Before taxes minus income taxes—this is what the business earned during the period. It is added to the balance sheet and increases the net worth. This term is often called net profit or net earnings.

Net sales

This is the total dollar volume of all cash or credit sales less returns, allowances, discounts, and rebates.

Operating expenses

These are the selling expenses, administrative expenses, and overhead expenses required to run the business. It excludes cost of goods sold, interest, and income tax expense. Examples of these costs are rent, utilities, and administrative departments such as accounting, marketing, human resources, etc.

Operating income

This is the amount left over after subtracting operating expenses from gross profit.

Cash flow statement terms The following is a list of terms and their definitions that are used in cash flow statements. Term

Detail

Cash sales

This is the cash received from customers for goods sold and services performed.

Equipment

This is the money spent to acquire equipment (fixed assets) required to run or expand the business.

Furniture and fixtures

This is the money spent on procuring furniture and fixtures for the organization.

Income taxes

This is the money paid to the authorities on profits and other income earned.

Interest received

This is the money received from deposits, cash invested in money, and other external investments.

Inventory

This is the money used to purchase items held for sale or used during the manufacture of products that will be sold.

Investment contribution

This is the cash given to an organization for an interest in the ownership of the business (usually stock).

Loans/borrowing

These are funds received from financial institutions or investors by the issuing of a debt.

Operating expenses

This is the cash used to pay costs arising from the day-to-day operating of the organization such as salaries, rent, and utilities.

The Handbook of Financial Modeling

Balance sheet terms The following is a list of terms and their definitions that are used in balance sheets. Term

Detail

Accounts payable

Also known as creditors, this is the total amount of money owed by the organization to all suppliers on credit.

Accounts receivable

Also known as debtors, this is the total amount owed to the organization by suppliers but the cash has not yet been received.

Accruals

These are costs and expenses that have been accumulated against current profits but have not yet been physically paid for.

Assets

This is the value of all cash, land, buildings, equipment, and inventory that an organization owns.

Cash

These are items immediately accessible to be used as cash.

Common stock

This is money provided to the organization in order to have a piece of ownership by parties who will then become investors in the organization.

Current assets

This is the total of all cash, accounts receivable, inventory, and any other item that can be converted into cash in less than 12 months.

Current liabilities

This is the money that is due to the organization during the course of its activities that will be paid within 12 months.

Depreciation

An accounting procedure that puts a valuation on the physical assets of an organization over the assets’ useful life.

Fixed assets

These assets can be land, buildings, furniture and fixtures, equipment, patents, and goodwill.

Inventory

This is the total amount of physical goods owned by the organization intended to generate revenue irrespective of its state (raw or finished) or its location.

Liabilities

This is everything that a company owes to creditors.

Retained earnings

This is the profit that is kept in the organization and thus has not been allocated to shareholders.

Owner’s equity

This is the difference between assets and liabilities, which in theory is the amount due to shareholders.

331

APPENDIX

B Ready-Made Functions Listed are a number of functions that I have found useful for modeling that you can copy and use. These functions will be beneficial to have in your function library. I have provided a list of these functions and a short brief on how to enter them. Adding functions Open the Visual Basic Editor (VBE) from Tools ➤ Macro ➤ VBE (keys: ALT+F11). In the Project Explorer pane, select VBAProject (Book1). This selects the empty workbook (Figure B-1).

Figure B-1.  The VBAProject window has a list of all the worksheet objects in the current workbook

© Jack Avon 2021 J. Avon, The Handbook of Financial Modeling, https://doi.org/10.1007/978-1-4842-6540-6

334

Appendix B | Ready-Made Functions If you were already working in Excel, the name might be different. Check the name in the title bar of the Excel window if you aren’t sure. If the Project Explorer is not visible, open it by going to View ➤ Project Explorer. From the Insert menu, choose Module (Figure B-2). This adds a new empty code module to the selected workbook. You will also see the module appear in the Project Explorer pane.

Figure B-2.  The Insert menu is where you add the module. This brings up the code windows, where you type the code

Find Saturday The key feature of this function is not that it finds Saturday but that you can change the weekday to any day that you choose. I use this function when I need a specific weekday to trigger some event. Here’s the code: Public FunctionFindSaturday(InputDate As Date) ' Returns the date of the first Saturday following the Inputdate    FindSaturday = FormatDateTime(InputDate + (7 - Weekday (InputDate))) End Function Remove spaces This particular function removes spaces from text, but its strongest asset is that it can be modified to remove just about anything simply by changing the strInput “ ” to whatever you need. This is an extremely useful function when dealing with data, particularly CSV files1. 1

 SV stands for comma-separated values. A CSV file is a text document that can be read C by Excel and all the Microsoft office applications.

The Handbook of Financial Modeling Here’s the code: Public Function RemoveSpaces(strInput As String) ' Removes all spaces from a string of text Test:    If InStr(strInput, " ") = 0 Then       RemoveSpaces = strInput    Else       strInput = Left(strInput, InStr(strInput, " ") - 1) _       & Right(strInput, Len(strInput) - InStr(strInput, " "))       GoTo Test    End If End Function Sum colors This function calculates totals based on colors. It’s very useful when reviewing models as you can color-code specific cells and use this code to check the values based on those colors: Function SumColor(rColor As Range, rSumRange As Range) 'Sums cells based on a specified fill color.         Dim rCell As Range         Dim iCol As Integer         Dim vResult         iCol = rColor.Interior.ColorIndex                 For Each rCell In rSumRange                         If rCell.Interior.ColorIndex = iCol Then                                 vResult = WorksheetFunction. Sum(rCell) + vResult                         End If                 Next rCell         SumColor = vResult End Function

335

336

Appendix B | Ready-Made Functions Count colors This function will count a range of cells based on their fill color. It is activated by choosing a fill color and pointing the formula to the cell and then choosing the range to count, as in Figure C-3: Function CountColor(rColor As Range, rSumRange As Range) 'Counts cells based on a specified fill color Dim rCell As Range Dim iCol As Integer Dim vResult iCol = rColor.Interior.ColorIndex    For Each rCell In rSumRange     If rCell.Interior.ColorIndex = iCol Then          vResult = vResult + 1     End If    Next rCell CountColor = vResult End Function

Figure B-3.  The CountColor() function used will count the number of cells in a range that conform to the designated color

The Handbook of Financial Modeling Sort using colors This is another of the sort functions. With this function, you can apply different colors and assign a sort priority, which is useful for checking and testing data. Here’s the code: Function ColorRank(ColorOrder As Range, LookCell As Range)         Dim i As Integer         Dim ICol1 As Integer         Dim ICol2 As Integer         i = 1         ICol2 = -1         ColorRank = 0         'Loop until match is found         Do Until ICol1 = ICol2                 'Replace "Interior" with Font to sort by Font color                 ICol1 = ColorOrder(i, 1).Interior.ColorIndex                 ICol2 = LookCell.Interior.ColorIndex                         If i = ColorOrder.Rows.Count + 1 Then                                 'No Match found place in Text                                 ColorRank = "No color match!!!"                         Exit Do                         End If                 'Pass the Row number of the color match                 ColorRank = i                 i = i + 1         Loop End Function Sum the bottom and top numbers in a range I use this function to test the validity of data when it has been copied again or refreshed to test if there have been any changes.

337

338

Appendix B | Ready-Made Functions Here’s the code: Function SumTopBottomN(rRange As Range, N As Long, Optional bBottomN As Boolean) As Single Dim strAddress As String On Error Resume Next strAddress = rRange.Address     If bBottomN = False Then         SumTopBottomN = Evaluate("=SUMPRODUCT((" _             & strAddress & ">=LARGE(" & strAddress & "," & X & "))*(" & strAddress & "))")     Else        SumTopBottomN = Evaluate("=SUMPRODUCT((" _             & strAddress & "