In project finance, and in contrast to a perpetual corporate entity, the financial model structure varies significantly between the versions that are used for the financial close, the construction project phases, and the operational phases of an asset’s life. 

Transitioning from transactional models to operational models at the appropriate time in the asset life cycle is key to achieving the long-term benefits to infrastructure project management. In this article, we detail each phase and discuss financial model considerations.

Construction phase

During the construction phase, the focus of the model is on the timing of capital expenditures, drawdowns from debt and equity facilities, and the matching of capital uses with sources. It often features a monthly timing tab to closely monitor the construction progress and project cash flow needs. 

This model must be flexible enough to accommodate various changes in costs, debt structure, and pricing, as these will impact the project’s financial viability and the sponsors’ internal rate of return (IRR). During this phase, there may be a high degree of model manipulation as the project iterates toward a final financial and commercial structure. Additionally, during this process, debt and equity lenders generally require a comprehensive set of model stress tests and scenarios to be undertaken in order to understand the dynamics of the structure and assess its inherent risk parameters. This naturally leads to a high degree of model complexity to accommodate the need to flex a range of inputs including construction costs, schedule, interest rates, reserves, inflation rates, and debt/equity splits.  

Final transaction

Once the final transaction structure is agreed upon, and commercial and financial close is achieved, then this model is escrowed in a secure third-party location to preserve it. The project then moves into the construction phase and, with the first drawdown of funds and construction expenditure, the planned timings almost inevitably change. This frequently requires iterative updates to carefully manage the cash, drawdown, and construction expenditure aspects of the project. Often this is undertaken by updating a new version of the escrowed model with successive iterations as work progresses. During this time it is critical to maintain control over these versions by establishing clear protocols for naming conventions and update logs.

Post-transaction close

Post-transaction close, as the project moves into the operational phase, the financial model’s structure becomes more stable and long-term focused. The high degree of detail and functionality associated with the various funding and financing facilities, the tracking of the construction of the asset for tax and accounting purposes, and some of the stress testing capabilities will no longer be needed. As a result, the timing may shift to quarterly or semi-annual periods. 

The model requirements now focus more on operational revenues and expenses, debt service, and maintenance of reserve accounts. It becomes crucial for determining the project’s ability to meet its debt obligations and generate returns for equity investors. The operational model typically includes detailed calculations for metrics like the Debt Service Coverage Ratio (DSCR), other compliance and covenant requirements, and IRR calculations in accordance with the operating agreement. Additionally, it can also be used to prepare tax estimates for current or future periods, and incorporate true-ups for actuals. All of these functions are essential for ongoing financial management.

Shifting from a construction-focused to operational financial model

The transition from a construction-focused financial model to an operational one involves a shift in the model’s inputs and outputs. For instance, during the bid stage, the DSCR is an input to determine leverage; but post-financial close, the leverage becomes an input, and the resulting cover ratios become outputs. This reflects the change from a dynamic, negotiation-driven environment to a more predictable, performance-driven one. Interest rate swaps and other financial instruments may also be executed at financial close, further solidifying the financial structure and locking in various requirements and metrics as the project moves into its operational life.

Operational models

It is therefore quite common to migrate the project model into a completely new format for the operational phase. Just like the transactional model, this model can be built for its intended purposes and, in many cases, significantly streamlined. Operational models are generally smaller and less complex than their construction counterparts but, nevertheless, contain important elements that can support the efficient management of the asset. As noted above, operational models focus primarily on capturing quarterly or semi-annual inputs based on the performance of the asset to capture real-time updates for management and reporting purposes. They may also be able to re-forecast performance in the future so that management can understand how current performance will affect the long term.

Case for migrating from transactional models

Often, however, transactional models are used to capture ongoing updates. This approach can have some benefits as the model is generally familiar to the users and reviewers, and can be easily interpreted. However, in the long term, it generally becomes inefficient to undertake the financial management of the project using this tool. Often the core functionality of the model has not been constructed with operations in mind and, therefore, a lot of reworking and rebuilding needs to be undertaken just to get the model to perform its new set of functions. This can lead to risks around model functionality and robustness.

Multi-asset models

Additionally, if the assets are part of a portfolio or a fund, they may be required to roll up into a multi-asset model in order to calculate returns and performance at the portfolio or fund level. These can include various structures of the corporate organization such as project company or holding company structures; many of which may have different tax and reporting requirements. As financial close models are rarely standardized this can be a challenge. It often makes sense to undertake a process of standardizing and simplifying the models for the operational phase by building them with those specific requirements in mind. This upfront effort and cost can often quickly pay off due to the ongoing reduction in resources required to update the model and its ability to integrate more effectively into other parts of the business.

If the models are closely matched to the required debt covenants, periodic reporting information, and requirements of management, it is possible to make these models quick and easy to regularly update. 

Automation in finance

Finally, advances in the suite of financial analysis software are increasingly making automation of many of the processes associated with periodic updates more practical. Taking the time to set models up that can directly interface with other reporting software can significantly streamline the entire process. 

In summary, it is strongly recommended to consider the conversion of transactional models to operational models at the appropriate time in the asset life cycle. This can bring long-term benefits to project management, making periodic processes more efficient, and reducing the risk profile and resource requirement for operating the models; It can also bring benefits associated with portfolio-level standardization. Furthermore, considering how to automate these processes can further enhance efficiency.