The workflow before#
Sunrock invests in and runs solar projects, and each project lived in two Excel models. A banking model held the financing projections lenders cared about. An operational model tracked how the project actually performed. The two drifted apart as each was updated on its own schedule, and errors crept in at the seams. When someone asked what assumptions sat behind a past decision, the answer often meant digging through old spreadsheet versions for days. Every forecast came out as a single number. Solar yield, financing terms and operating costs all vary, but the models had no way to show how far the outcome might swing.
What we built#
We merged the two spreadsheets into one financial twin: a single, version-controlled model of each solar project that covers financing and operations together. It records every run, so the team can pull up the exact scenario behind any past decision. And it answers with a range of outcomes instead of one number, because a solar forecast is a bet on the weather as much as on the finances.
One model instead of two
Financing and operating logic now live in the same model and read the same inputs. We chose one model over two linked ones because the drift lived in the handoffs between files. Take the handoff away and there's nothing left to reconcile, so finance and operations look at the same numbers when they sit down together.
Forecasts as a range
We extended Sunrock's existing Python model with PyMC, so uncertain inputs like solar yield and financing terms become probability distributions. Each forecast run simulates 10,000 scenarios and shows the spread of cash flow and returns, from the likely case to the downside. We built on the team's deterministic model rather than replacing it, so the logic they already trusted stayed intact.
Recall any past scenario
Every input set and output is versioned and tied to the model version and run. When a lender or an investment committee asks what the team assumed last spring, an analyst can reproduce that exact result in minutes. It's just as easy to put today's forecast next to the one that justified a decision.
How we delivered it
We started from the team's existing Python model and the two Excel files. We merged the models first, then added the probabilistic layer once the combined version matched the old outputs. We also designed the target architecture on Microsoft Fabric, with lakehouses for raw and cleaned data, a warehouse for reporting and the Python models running next to the data, so the twin has a clear home as it grows.
Before and after#
| Measure | Before | After |
|---|---|---|
| Models to reconcile | 2 Excel files | 1 versioned financial twin |
| Forecast output | One deterministic number | Full probability range across 10,000 scenarios |
| Recalling a past what-if | Rebuild from old spreadsheet versions, often days | Exact recall in minutes |
What's next#
With every scenario versioned in one place, the next step is letting finance ask the model questions directly, such as which projects carry the widest downside or how a change in financing terms shifts returns across the portfolio, instead of waiting for an analyst to rerun it.




