The document discusses operational financial models used to monitor PFI/PPP projects in the current credit crunch environment. It provides guidance on creating a good operational model, noting it should: 1) provide a clear audit trail from the original financial close model; 2) produce reports required by contracts; and 3) be designed to integrate management accounting data. It also stresses the importance of independent audits of operational models to ensure accuracy and integrity given increasing tensions between shareholders and lenders. Overall, it emphasizes the need for engagement between projects companies and lenders in the operational modeling process.

1. Operational modelling (in the credit crunched world)
Jerome Brice, November 2008
An version of this article appeared in the PPP Bulletin.
Key terms: model audit, project finance, financial modelling, PFI, PPP, operational
modelling.
http://www.mazars.co.uk/projectfinance
jerome.brice@mazars.co.uk
In the light of the credit crunch, banks who have lent to PFI projects are inevitably
becoming much more interested in the health of their existing loan commitments. In
practice this means that banks are putting a greater emphasis on requiring project
companies to demonstrate that the bank’s contractual covenants are not being breached
either at the ‘lock-up’ level, which prevents shareholders making distributions, or at the
‘default’ level, which could give the bank the opportunity to demand repayment of any
outstanding balance and/or renegotiate funding terms.
The tool which is commonly used to monitor such covenants is the project financial model.
For practical reasons this financial model is not usually the model which was used for
financial close purposes but is instead a separate ‘operational’ model. This is a model
which while being based on the financial close model also contains the functionality to
allow revised forecasts of bank covenant metrics and shareholder returns on the basis of
actual operating performance.
At Mazars we have audited over 30 such operational models in the last 12 months, which
has given us some fresh insights into what makes a good operational model and how both
shareholders and banks can successfully manage the operational monitoring process in
these more challenging times.
A good operational model
In our view, a good operational model will meet the following requirements, it will: provide
a clear audit trail from financial close assumptions to the most recent operating period;
provide reports which meet the requirements of contractual documents; be designed to
dovetail with management accounting data and be built in accordance with financial
modelling ‘best practice’.
When an operational model is created it is important that both banks and shareholders
have confidence that the results it produces are consistent with the original agreed
financial position as encapsulated in the original financial close model. The best way to
do this is to input the financial close assumptions (including opening balance sheet and

2. revenue, cost, inflation, and other projections) into the operational model. Theoretically,
the operational model should then report exactly the same results as the financial close
model. There are a number of reasons why it invariably does not, these include: contract
variations agreed since financial close; changes made to the accounting and tax
treatments; calculation errors in the financial close model that have been corrected in the
operational model, and new calculation errors introduced in the operational model. It is
important that the reasons for any change to the original financial close position are fully
understood so that a solid baseline is created for future reporting.
When creating the baseline operational model some thought is required to ensure that it is
able to accept management accounting information. Operational models typically produce
forecasts by taking the balance sheet data from the latest set of management accounts
and then projecting these forward on the basis of the financial close assumptions, as
amended for agreed changes in operational and economic assumptions. The clear focus
here should be on ensuring the management reporting systems meet the requirements of
the project and not as some project accountants might like – the other way around! That
said it can be useful to increase the periodicity of the model from that envisaged at
financial close to meet operational requirements. Typically, the financial close model is
based on a semi-annual periodicity to match debt repayment periods and procuring
authorities March year ends. However, this is often out of sync with the statutory reporting
requirement of the project company and its shareholders who often have to report in
December. Therefore, operational models are commonly produced with a quarterly
periodicity and with the advent of Excel 2007 (with its 16,384 columns) we are now also
beginning to see monthly models.
As well as providing the facility to input actual data the model should also contain
functionality to sensibly incorporate items that were not included at financial close. For
example, while the financial close model and documentation may not have anticipated any
working capital assumptions (as invoices were due to be settled in the months they arise)
the reality of running an operational company is that such requirements almost always
arise. Therefore, models should not just include the functionality to include working capital
but also a sensible (and agreed) mechanism for unwinding these positions in future
forecasts. We are used to seeing models where the choice is either to completely unwind
the position in the next project period or alternatively to assume that they are projected
through until the concession end. Neither assumption is likely to hold in reality and the
impact on reported cashflow is usually significant.
It should also go without saying that models should conform with best practice in terms of
their structure and coding. While there is no industry standard for what ‘best practice’
means, in this context we would expect the model to:
- clearly highlight input assumptions
- contain short, easy to understand formulae
- be flexible enough to incorporate future updates
- be accompanied by full documentation of assumptions and instructions for model
operation

3. These last two items are worthy of further discussion. With regard to flexibility, our view is
that the focus of the operational model should be to concentrate on fulfilling its prime
purpose i.e., meeting the reporting requirements of the credit agreement. If the model is
designed to do more than that, this inevitably leads to an increased risk of error. However,
that is not to say that the model built should not be capable of future adjustment and a
model built in a modular format will allow future changes including future contract
variations, proposed refinancings, switch over to International Financial Reporting
Standards etc. With regard to documentation, the model should be accompanied by clear
instruction on how to update it and this should include where necessary references to the
underlying contractual documentation. Such instructions would appear to us to be
fundamental to any tool which purports to be a contract monitoring tool - but in our
experience these are rarely provided.
Managing the conflicting requirements of shareholders and bank
In current market conditions there is inevitably increasing tension between the
requirements of shareholders - demonstrating the ongoing soundness of the project and
ensuring appropriate shareholder distributions are made, and senior funders - ensuring
distributions are locked up where appropriate and events of default are reported. As a
result, and as one might expect, we believe it is essential that any operational model that
is going to be relied upon as a contract monitoring tool should be subject to an
independent review i.e., a model audit. As well as providing an independent view the audit
also helps ensure model integrity. Of the many audits we have undertaken there has not
been one instance where we have not recommended an amendment be made for at least
one of the following reasons:
- lack of a clear reconciliation to the financial close model
- models which while correct in the base case are not capable of providing accurate
outputs once updated for actual data
- errors which existed in the financial close model have been replicated in the
operational model
- accounting and tax policies which no longer reflect revised standards and
legislation
- outputs which do not meet the requirements of the credit agreement e.g.,
incorrectly calculated cover ratios.
In my personal view, it is perhaps surprising that senior funders have in the past few years
ceded control of both the selection of the operational model builder and the choice of
model auditor to the project company. Even more surprising is that some senior lenders
do not require a duty of care from the model auditor even when an audit has been carried
out. Given the current climate I would expect senior lenders to become increasingly
vigilant – and this will have consequences for the way that operational models are
procured, constructed and audited in the future.
The above discussion has highlighted some pointers which should assist in producing a
better operational model. However, the most important factor in determining whether the
operational model is a good monitoring tool does not ultimately lie in selecting a good
model builder or (I hesitate to say!) in selecting a good model auditor. Instead the key to

4. success is the engagement of both the project company and the bank in the operational
modelling process and their commitment to understanding the underlying financial and
contractual position. If such joint understanding is present, there is hope that even in the
prevailing market climate, a smooth operational reporting process can be initiated which
avoids the misunderstandings that can lead to costly disputes.