Investor Diligence Checklist for a Solar Project

This checklist covers what an investor examines before committing capital to a solar project: the documents, assumptions and rights that must hold up before money moves. It is organized by workstream, the way diligence actually runs, so a developer preparing a project and an investor reviewing one can work from the same list.

Use it well before anyone asks. A developer who runs the list at the start of a sale or financing finds the gaps while there is time to close them, which is the difference between a short delay and a repriced deal. An investor uses it to structure a review and decide early which items are deal-relevant, since diligence exists to find the few items that change the answer. Most findings are fixable; finding them late is what damages a transaction.

Resource Hub · The Energy Academy

Investor Diligence Checklist for a Solar Project

Work through an investor diligence review of a solar project, from ownership and site control to the financial model. Tick items as they clear, mark what does not apply, and print or export your list.

Investor Diligence Checklist for a Solar Project
0 of 59 items closedYour progress saves in this browser.
Download blank PDF

Diligence starts by establishing that the seller owns what it is selling and can transfer it cleanly. This work is unglamorous, and it is where deals quietly die, usually over a signature from an earlier stage that was never properly obtained.

Site control is binary: either the project has the legal right to occupy the ground for the full term, and to reach and connect it, or it does not. Partial answers become title exceptions, and title exceptions become conditions to funding.

Permits are reviewed for what they require after issuance as much as for their existence. A conditional approval with an unmet condition is functionally no permit, and conditions are often buried in a resolution attachment.

Interconnection is the largest source of late-stage cost surprise on most projects. The questions are what the project may inject, what it must pay for, and what remains to be built by a party the developer does not control.

Revenue contracts are read for the terms governing bad outcomes, not the price. An investor is buying a payment stream whose value depends on who is obligated, for how long, and what excuses performance.

The technical review establishes that what is being built matches what was modeled, and that someone creditworthy must finish it. An independent engineer normally does this work; the investor sets its scope.

Production drives every revenue line, so its analysis draws more scrutiny than any other technical input. The review is less about the central estimate than its basis and uncertainty.

Operating arrangements determine whether modeled expenses are real commitments or estimates. Insurance determines who pays when something breaks.

The model is reviewed last, because it is only as good as the documents behind it. This pass confirms every assumption traces to something reviewed above.

Adapt the items to your project and use them alongside the governing documents and your advisors. Ticks and notes stay on this device only.

How to use this checklist and what it does not replace

Work it as a status list rather than a questionnaire. Each item gets an owner, a document reference and one of three states: satisfied, outstanding with a plan, or a genuine issue. The value sits in the third category, and the discipline is not letting items rest in the second without a date attached.

Scale the depth to the transaction. A small distributed project does not warrant utility-scale depth, but the categories still apply, and skipping one because the project is small is how a fatal land or interconnection issue gets missed. On a portfolio, run the list per project, since the defects that matter are almost always site-specific.

This checklist does not replace the professionals who do the work. Legal diligence, title review, independent engineering, insurance brokerage and tax and accounting review are specialist functions whose reports are the evidence behind most items here. Requirements also vary by jurisdiction, utility and transaction structure. Treat this as a framework for organizing a review, not a substitute for advice on a specific project.