At Operis, we work with financial models day in and day out. However, our clients have a much broader job description. So when it comes to monitoring projects that are already operational, in some cases, they might not have dealt with an operating model before.
If you are commissioning an operating model, we suggest the following scope items as a starting point for your Request for Proposals (RfP) that you send to modelling firms like us. In square brackets are the points you will most likely need to customise to your project and company-specific requirements.
For ease of use, we have created a downloadable scope that you can copy and drop into your RFP template and edit to match your actual needs.
Below is the scope with an explanation of why we recommend having each item.
A note on terminology – the operating model, is sometimes referred to as the budget or monitoring model. The financial close model might also be called the transaction model.
The model shall contain the following:
1. Financial statement projections (profit and loss, cash flow and balance sheet) for the project
Well laid out, the financial statements clearly show the current state of the project and future trends. Having all three financial statements present in the model with double-entry accounting also provides a good basis for structural audit tests that everything is behaving as it should.
2. An interface that accepts actual data for historic periods in the format of [trial balances/financial statements as per the accounts] and additional standalone items as required to reflect events to date and forecast forwards from the final position reflected by those actuals
Historic inputs should be in whatever format the project company already has, which saves time every update cycle. Additional items needed (e.g. tax depreciation balances, cash debt balances, historic inflation) should be put in the same place to reduce the risk of them not being updated.
3. Revenue and cost calculations on the basis of operational, financial and economic assumptions in the [base case financial close model and in line with core project documentation]
The assumptions in the existing financial close model can be used as the basis for the operating model. You then only need to document by exception the items where there have been contract changes etc.
4. An interface for controlling the release timing of receivables/payables balances
There might be items on the balance sheet that you do not expect to clear in the near-term future or even at all. If the model cannot adjust for this, it may forecast a cash shortfall problem in the immediate future.
5. [Senior funding calculations based on a fixed repayment schedule with associated debt service reserve and other accounts as required], forecasts of loans from the partners, and equity
The funding structure is now agreed upon, and the repayment profile is set, so the model can be made lighter without losing functionality that is still needed. This bullet can be updated to reflect the senior facilities and reserve accounts that the project uses. You can also mention this here if you would like to show the indicative effect of a simple refinancing. Though the likelihood is that any refinancing transaction would require a specific transaction model, and then the operating model would be updated to reflect the refinancing debt after the transaction had gone through.
6. Tax and accounting assumptions and treatments replicating those employed in the [financial close model]
The financial close model methodology can be used as a basis for tax calculations. If there have been changes in tax legislation that will need modelling, do note that.
7. Calculation of [key financial covenant lender ratio calculations (ADSCRs and LLCRs)] in line with the [financial close model and financing documentation]
One of the main reasons that an operating model might be required is to report cover ratios to the bank – include the ratios you need to report here (check the loan agreement).
8. Calculation of [shareholder returns and the project valuation on a discounted cashflow basis]
This bullet is for the metrics your shareholders want to track. They might use, e.g. EBITDA multiples instead of discounted cashflows, so use their preferred approach here.
9. A reconciliation of the model’s cashflow to the [base case financial close model]’s cashflows, where any discrepancies are explained by agreed changes in approach or inputs
Providing a mirror scenario that reconciles to the financial close base case (e.g. assuming everything turned out exactly as expected) is a key part of getting sign-off from banks and shareholders to start reporting based on the new model.
10. The ability to store different scenarios and to sensitise key drivers of cashflows
It can be useful to see what impact increasing costs by a certain amount or percentage might have on your cover ratios, or how a change in inflation might affect your returns. You can specify what sensitivities you are interested in, if you know, and even ask the modeller to set them up as different scenarios that are variations on your base case.
11. An output sheet which summarises the key forecast assumptions being used by the live case in the model
This is so you can easily see what drivers are being used in differing model versions/scenarios.
12. A change log which allows the tracking of movement in [the project valuation and minimum forecast ADSCR]
This means that you can easily quantify what impact various assumptions changes have had and produce bridge graphs between different model versions – use the metrics your stakeholders are most interested in.
13. Summary output sheets to present key project information, including graphs of key items [and an output for extracting current information for cover ratio certificates]
Graphs show key trends without needing to dig into the model’s detail. If you are using the model to complete cover ratio certificates, an output that reports the relevant numbers (as per the loan agreement) may save time and reduce the risk of errors.
The model will have the following characteristics:
1. Compatibility with [Microsoft Excel 365 for Windows]
The Model needs to be compatible with the relevant version(s) of Excel – which might include what you use, what the bank uses, or what the shareholders use.
2. Adherence to the ICAEW standards of best practice financial modelling or another recognised code of best practice
The ICAEW standard is very principles-based and not specific to any firm.
3. Contains separate areas for inputs, workings and summary outputs
This is a key element of model design to make the model easier to read and operate and reduce the risk of errors.
4. Contains an audit sheet which self-checks the model and differentiates between commercial checks and structural model issues
Live checks in the model are key for having confidence in the model’s results. It helps to split these between commercial points (e.g. covenant breaches, forecast overdrafts) and structural issues (e.g. a balance sheet imbalance that might be introduced if someone accidentally overwrites or deletes some of the workings), as the former are for your information and the latter require action.
5. Be accompanied by a user guide with instructions for updating the model.
Given the lifetime of the project, it is likely that the model will have more than one user. Having a user guide helps with succession planning.
If all this talk of model scopes has inspired you to send us an RfP, please reach out to email@example.com; we’d be delighted to assist you.