Story Ian Bennett and Farouk Dahbourah

Project finance depends on the contracted and forecast long-term cash flows of an underlying project, rather than concepts such as EBITDA, balance sheet or other corporate measures (covenants) and KPIs. Infrastructure assets are classic project finance territory, where the debt and equity is paid back from the cash flows generated by the projects – for example, solar/wind farms backed by long-term purchase price agreements (PPAs).

This heavy reliance by multiple stakeholders on the forecast cash flows that arise out of detailed contracting arrangements, in complex equity and tax structures, over long periods, demands the most elegant of financial models to bring transparency to the entire project.

In this article, we will shed light on the mysterious world of project finance (PF) models and what project finance teaches us about financial modelling.

Project finance is to modelling what the “500-piece, double-sided Penguins Jigsaw Puzzle, with no picture on the box, which contains 20 pieces that aren’t required” is to puzzles. You must:

(i) think twice before you place any piece
(ii) understand the components of each section, and
(iii) understand the relationships between each section and how they will seamlessly come together.

The figure below shows some of the common project finance modules, but there are more.

Click image to enlarge.

What makes a project finance model unique?

(a) Solving for financing, then feeding that back

At its core, the model uses inputs (operational, tax, accounting and financing) to produce primary outputs (mainly debt repayment profiles), then these outputs are used as inputs to determine the distributions to equity investors. Adding to the complexity, this requires any PF modeller to learn VBA in order to avoid the circular reference.

Remember: (i) no two debt-solving macros are the same; (ii) there’s no excuse for a circular reference.

(b) Must see the complete puzzle

Unlike many types of models, to use the model in any way, or even to start sense-checking the outputs, you need to have all of the components correct and interacting properly with each other (if one is down, all are down!).

Remember: Don’t leave tax and accounting to the end as they can have a material impact on debt, equity distributions and returns.

(c) The journey of testing

Do not be fooled that your work is done if you built the model according to the specification. The testing stage is critical, and for PF models it must be done repeatedly with meaningful numbers. All model stakeholders will go through stress-testing and uncovering certain outcomes under scenarios that were never considered. It’s hard to imagine how PF modellers who hand over unpopulated or template models can sleep at all.

Remember: The considerable testing phase should not be seen as a reason for dispensing with the specification phase, without which the testing phase is very long, painful and expensive.

What will help in keeping it simple?

(a) Forget the template

Let’s be clear: there is no template PF model. Every project has a combination of characteristics that makes it entirely bespoke. Any template model that would be even 95% correct for any project, even any solar farm, would be too complex to be used to finance 95% of projects.

But worse, the time spent unpicking and amending the template, and removing redundant sections, and fixing resultant and inevitable errors, would far exceed the time spent building it from scratch.

Remember: Templates are good for teaching PF, but are dangerous if used in a real project.

(b) Follow an approach and stick to it

PF modelling is no exception to the rule that every model must be specified before it is developed. Scoping and specifying your PF model is an enjoyable journey for you and your stakeholders, as you define and agree on the story you are trying to tell and the questions you want the model to answer. Things start to look and feel simple when you have the frames of the puzzle and slowly bring the other pieces together.

“Things start to look and feel simple when you have the frames of the puzzle and slowly bring the other pieces together.”

Remember: Great PF modellers can make each model look like it was developed from a template but in reality is uniquely simple.

(c) PF models don’t have to be complex

Building your first PF model is a huge achievement. Your blood, sweat and tears have paid for a valuable set of skills and knowledge that has you desperate to start your next project. The definition of success for any financial modeller is that their final model is perceived as simple. However, this belies the effort required, so some modellers create complex models to attract the appropriate recognition.

Remember: A PF model should appear simple, despite the extraordinary complexities that must be navigated to achieve this. There is no room in our profession for complexity for the sake of complexity.

(d) “Sources of cash” must equal “uses of cash”

At any point (for every column in the model), sources must equal uses. That’s not a check you do at the end, but keeping a close eye on this throughout the process will make it almost enjoyable. 

So, you want to build your first PF model?

1. Mixed timeline

Almost every model reviewed that has been built with mixed timeline granularity (for example, monthly and quarterly on one sheet) had an error. Time and again, the transition from construction to operational phase doesn’t work, or working capital has a big error. Given the size of PF models and the nature of the assumptions and other dynamics, a few extra columns will make very little difference and is preferable to a design that will lead to errors.

2. Never take off your seatbelt

Ruthlessly applying model design best practices are considered a financial modeller’s seatbelt. While it’s tempting to dip into the Axis of Spreadsheet Evil to find technical shortcuts to get something across the line quicker/faster/fancier, such an approach could be deadly in a PF model. Using an OFFSET( INDEX( MATCH, MATCH)) formula is unforgivable.

3. It’s not only about the IRR

While the internal rate of return (IRR) is one of the core outputs of a project finance model, it can be misleading. It’s critical that you look at all the key output metrics every time the model is solved (or not solved), especially in the last periods of the project: for example, what are the fixed assets balances, what is the debt balance, is the minimum cash balance being released, etc.

Remember: The KPIs are specific to your project sponsor, and should be agreed during the specification.

Many people join our team with the ambition of learning to build PF models because of its perceived status in the hierarchy of financial models. But that status is mostly undeserved. The approach taken, commercial knowledge required, quality of the financial modeller, experience of the project manager and definitions of success are much the same as any other financial model.

A great financial modeller can build a great PF model, and a great PF modeller is “just” a great financial modeller.

Ian Bennett FCA leads PwC Australia’s deals modelling team. He is joined for this article by Farouk Dahbourah, director in PwC’s deals modelling team and a project finance modelling specialist.

YOUR QUESTIONS ANSWERED

Have a financial modelling or spreadsheet question you’d like answered in Acuity? Send it to [email protected] with ‘Ask Ian’ in the subject line.

Read more: