Co-located projects create an apparently simple question: if a BESS is attached to an existing Solar PV plant or Wind Farm, should both be managed as one project?

At first, merging them can seem convenient. They may share a grid connection, substation, land, permits, SPV or development team. Their economics may also be presented together. And in many financial models and portfolio spreadsheets, combining them into a single row makes life easier.

But convenience at the spreadsheet level can create a much bigger problem at the portfolio level:

You lose information that may never be reconstructed.

The problem is not aggregation

There is nothing wrong with looking at a Solar PV plant and its BESS together. You may want to know:

Total MW or MWp.
Combined investment.
Consolidated project IRR.
Earliest or latest RtB.
Overall COD.
Total cost at risk.
Combined land requirements.
Exposure of the complete grid connection.

All of these are legitimate views. The problem starts when, instead of aggregating two projects, we turn them into one project record.

Aggregation is a view. It should not become your data model.

Imagine an operating Solar PV project

A 100 MW Solar PV project starts development in 2022. It secures land, progresses through permitting, reaches RtB, begins construction and achieves COD.

Three years later, the developer identifies an opportunity to add a 50 MW / 100 MWh BESS. The battery may benefit from existing grid infrastructure, land, permits or contracts. Commercially, it makes sense to consider both investments together.

Operationally, however, they are not the same project. The BESS may have a different development start date, different permits, a different investment decision, different risks and a completely different COD.

If both are merged into a single project record, what happens to the history of the original Solar PV plant?

Which construction start date is correct?

Suppose someone asks: when did construction start? There may now be two correct answers. The Solar PV plant may have started construction in 2024. The BESS may start in 2027.

The same issue applies to almost every important milestone:

When was RtB achieved?
When was the investment approved?
When was PAC issued?
When did the project reach COD?
Which permit is still outstanding?
Who owns the current risk?

Once both projects have been merged, the system may no longer contain enough structure to answer those questions properly. That is not just a reporting inconvenience. It is a loss of traceability.

Keep the projects. Model the relationship.

A much more robust approach is simple. Keep Project A — Solar PV — and Project B — BESS — as independent projects. Then explicitly tell the operating model that Project B is co-located with Project A.

You preserve the full history of both projects while still being able to analyse them together. You can calculate isolated values for Solar PV, isolated values for BESS and then consolidated values for the complete investment.

Nothing is lost. The aggregation remains available whenever the business needs it. But so does the drill-down.

Financial models helped create this problem

There is a practical reason why projects frequently get merged: spreadsheets.

A project-finance model may already contain hundreds of assumptions, formulas, financing facilities, tax calculations and sensitivities. Introducing a second independently modelled asset can make the workbook significantly more complex. The temptation is understandable: just add the BESS cash flows to the existing plant.

Something similar happens with portfolio spreadsheets. If a Solar PV project occupies one row, adding another row for the BESS can break formulas, portfolio counts, reports or dashboards. So the BESS becomes another column, a comment or simply part of the original project's figures.

The spreadsheet becomes easier to maintain. But the underlying business reality becomes harder to understand.

The limitation of the tool starts shaping the operating model.

That is the wrong way around.

There is also a financial reason to preserve separation

The distinction becomes especially important when BESS is added to an already developed or operating project. Much of the original Solar PV investment is now sunk cost.

The new decision is no longer whether the Solar PV project was a good investment. It is whether to invest additional capital in this BESS.

For that decision, understanding the incremental BESS cash flows and returns independently can be extremely valuable. That does not prevent the company from also calculating the consolidated return of the complete park.

A robust model should provide both: isolated economics and consolidated economics. Calculating the consolidated figure does not require destroying the individual ones.

Separate at the source. Aggregate at the view.

This is the broader data-governance principle. You can always merge information later. You can sum CapEx, combine cash flows, calculate consolidated IRRs, aggregate MW or take the earliest and latest of several milestone dates.

Going in the opposite direction is much harder. If somebody stores COD = 31/12/2027 after the Solar PV and BESS have been merged, you may no longer know whether that means:

Solar COD.
BESS COD.
The latest COD.
A contractual COD.
Or a manually selected consolidated date.

Once granularity disappears, software cannot magically recreate it. And neither can AI.

This matters even more in the AI era

Imagine asking: which BESS projects attached to operating Solar PV plants have a COD at risk, and which existing grid milestones could affect them?

That question requires the system to understand that the Solar PV plant is co-located with the BESS — while still understanding both as separate projects. If everything has been flattened into one record, part of that context has disappeared.

The AI may have more intelligence. But it has less reality to reason about. This is why good AI architecture starts much earlier than the LLM. It starts with the operating model.

How Navorda approaches co-location

Navorda is designed around this principle. Solar PV, Wind and BESS projects can remain independent operational objects while maintaining explicit relationships between them. Each project can preserve its own:

Land.
Permits.
Milestones.
Baselines.
Responsibilities.
Risks.
Financial figures.
SPV relationships.
Infrastructure dependencies.
Audit history.

At the same time, those relationships can support aggregated views of the complete investment or co-located park. You do not have to choose between detail and consolidation. A governed system should give you both.

The rule is simple

When a BESS is added to a Solar PV plant or Wind Farm: link it. Do not erase it.

Keep the projects independently identifiable. Model their dependencies. Share infrastructure where reality says infrastructure is shared. Aggregate financial and operational information where management needs an aggregated view. But preserve the underlying projects.

Because you can always go from detail to aggregation. You cannot always go from aggregation to detail. And in increasingly complex energy portfolios, that distinction matters.

Is your portfolio model preserving co-located projects as separate operational objects — or are spreadsheet limitations slowly flattening your project history? Navorda provides a governed operating layer for complex energy portfolios, preserving project-level traceability while connecting projects, infrastructure, risks and financial information across the portfolio.

Energy Critical Path: why plants, substations and power lines should not be managed as a single project

Navorda Platform — every project on one screen, filtered by technology, stage or region

The Cost of Delay: why energy development needs economic visibility, not just project tracking

Excel Isn’t the Problem. It’s the Symptom.