Heliosolve and PVsyst: what to keep, what to move, and what we cannot replace
If you are searching for a PVsyst alternative, the useful answer is probably not a replacement. In most utility-scale processes PVsyst occupies a specific position, the yield report that a buyer, an independent engineer or a lender is used to reading, and that position is held by convention as much as by capability. A feature list does not change that convention.
So this page does something narrower and more useful: it separates the layers, says which one we think is worth moving, and states plainly where we have nothing to offer.
Heliosolve publishes this comparison. PVsyst statements come from its public documentation, consulted on 15 September 2026; it is not a head-to-head test we ran on both products. PVsyst is a trademark of its owner and we are not affiliated with it.
Start with why PVsyst is the reference
Two independent observations:
- It is what teams are hired to use. Of 27 public job postings for design and project engineers at developers, IPPs and owner’s engineers that we read in September 2026, PVsyst appeared in 15, almost always as a requirement.
- It is one of the tools in the published blind comparison. Seven commercial tools (including PVsyst, SAM, SolarFarmer, PlantPredict, RatedPower, Solargis Evaluate and 3E SynaptiQ) were compared against measurements on two fixed-tilt monofacial systems, with annual-yield mean error up to 2.5 % (15.4 kW) rising to 6.0 % (14.5 MW) (Deville et al., Solar Energy 304, 114207, 2026). Heliosolve was not among the participants, and the study does not rank the tools by name in any form we can quote.
Note what that second point implies for any vendor claim, ours included: on the simplest configuration, with weather data supplied, the whole field sits within a few per cent. Nobody in that group has an accuracy argument that survives contact with the data. What differs is workflow, scope and what happens when the plant is not fixed-tilt monofacial.
And the layer where your report lives is the one where switching costs are highest, because the requirement is set by the recipient and not by you.
What each tool documents
| Work | Heliosolve | PVsyst documentation |
|---|---|---|
| Layout on real terrain | Searches configurations against LCOE and generates the arrangement; rows fitted to the ground | Detailed 3D shading scene defined by the user; terrain import |
| Electrical assignment | Optimises string-to-inverter and MPPT assignment | Automatic module-to-string attribution following user-selected rules — a related but different task |
| Parametric studies | Search driven by an objective (LCOE) | Parametric scan: runs simulations across user-defined ranges and steps, then compares results in a viewer |
| P50/P90 | Monte Carlo keeping correlations between uncertainty sources; one-year and tenor percentiles | Documented probabilistic evaluation: “P90 lies 1.28 σ below the mean”, with uncertainties added in quadrature on a normal distribution |
| Economics | Design carried through to LCOE, NPV and DSCR/debt capacity | Financial parameters, loans and economic evaluation |
| Environment | Browser application | Windows application |
| Third-party acceptance | No lender-acceptance track record | Widely used as a reference report (convention, not a documented guarantee) |
The table does not rank accuracy, depth or speed, and similar wording does not mean equivalent function.
The distinction that actually matters: objective-driven search versus parametric scan
PVsyst offers optimisation, and calling it “manual” would be false. Its parametric scan sweeps user-defined ranges and lets you compare the outcomes. Heliosolve searches for a configuration against one objective, levelized cost of energy, and uses the winner to generate the plant.
The difference is who holds the objective. In a scan, you enumerate the candidates and pick from the results; in an objective-driven search, the criterion is declared and the tool explores. Both are legitimate; the second is faster when the space is large and the criterion is economic rather than energetic.
Two honest caveats:
- The optimiser’s LCOE is a preliminary estimate. The energy and economic case is recomputed afterwards, and that is the number to review. A preliminary ranking that changes after the full calculation is a normal outcome rather than a defect, and it is why we show both.
- This says nothing about lower cost or higher yield by itself. It is a workflow claim, and it should be tested on your site.
Where a normal distribution is not enough
On the percentile layer there is a genuine methodological difference worth stating precisely, because it affects debt.
PVsyst’s documentation describes P90 as lying 1.28 σ below the mean, with uncertainties combined in quadrature on a normal distribution, which is the standard and transparent approach. The published evidence is that this approach is optimistic in the tail. Sandia’s modelling guide states that PV yield “is likely to be asymmetric about the P50” and that when input distributions are treated as symmetric, “energy yield forecasts tend to be overstated, and financial risk understated” (PVPMC). NREL quantified it in SAM: a P90 from a fitted normal came out 1.72 % high for fixed tilt, 2.91 % for single-axis tracking and 2.98 % for CPV versus the empirical distribution of 30 historical years (NREL/CP-6A20-54488, 2012).
Heliosolve builds the distribution by Monte Carlo, keeping correlations between sources and separating interannual variability (which averages out over the debt term) from model bias (which does not). We walk through the consequences in P50 vs P90.
What this does not mean: that our P90 is “more correct” for your project. A method being less optimistic in the tail is an argument about construction, not a validation. And if your lender’s IE expects the conventional calculation, give them both and show the difference.
A workflow that keeps both
- Decide which tool owns each deliverable, and write it down.
- Keep one reference configuration: equipment, geometry, weather, boundaries.
- Rebuild and review the inputs in each application. There is no automatic PVsyst project import, and importing a KML/KMZ boundary is not importing a project.
- Compare within the same scope and record effects that cannot be represented in both.
- Keep the reviews that live outside both tools.
When the two disagree, work the chain in order rather than arguing about engines. Given that assessors handed identical inputs still spread +18.8 % to +24.6 % on transposition alone while all claiming the Perez model (IEA-PVPS T13-18:2020), the decisions deserve suspicion before the software does. The procedure is in why two yield estimates differ.
What we cannot replace today
- The recipient’s requirement. If a buyer, IE or lender asks for a PVsyst report, that is a contractual fact. Confirm it with them; do not let any vendor talk you out of it.
- Lender familiarity. We have no acceptance track record. That is a real disadvantage and it is not solved by physics.
- Breadth of validation. Our documented validation against measured data covers one plant; PVsyst’s footprint across the industry is a different order of evidence.
What to ask for next
Bring one real task rather than a shortlist of brands: “I want to lay out this site against an economic criterion, see the electrical assignment, and follow it through to LCOE and debt capacity, then decide which part of my current process I keep.”
Ask to see configuration, automation, review and outputs, and ask where the tool stops. You can start on a sample project without sending confidential files.
Frequently asked questions
Is Heliosolve a replacement for PVsyst?
For most teams it does not replace it on the report layer, where the requirement belongs to the recipient. It can take over layout search, electrical assignment and the economic evaluation, which is a different question from replacing the yield report.
Can I import a PVsyst project into Heliosolve?
No. You can import a site boundary (KML/KMZ) and rebuild the case. Any parallel comparison requires reconstructing and reviewing the inputs in both tools.
Which one is more accurate?
Neither of us can answer that honestly from the public evidence. In the published blind comparison of seven commercial tools on fixed-tilt monofacial systems, annual-yield mean error ranged up to 2.5 % at laboratory scale and 6.0 % at utility scale, and the open-source validation work concludes that system-specific data availability matters more than model selection.
What is the real difference in P50/P90?
PVsyst documents a normal-distribution approach with uncertainties added in quadrature; we build the distribution by Monte Carlo and keep correlations. NREL measured the normal assumption as 1.7–3.0 % optimistic in the P90 versus an empirical distribution.
Do you support trackers, bifacial modules and terrain?
Yes, and so does PVsyst. Be aware that for those configurations there is no published blind comparison at all, because the 2026 study tested only fixed-tilt monofacial systems. Treat any accuracy claim about them, from anyone, as unverified by third parties.
Heliosolve limits and next step
Energy yield and financial returns are estimates under your project assumptions. Documented validation against measured data covers one plant; it does not validate every model or location. No lender-acceptance track record; small team. The software does not replace engineering review.
See also: how to choose solar farm design software · Heliosolve and PVcase · Heliosolve and RatedPower.
PVsyst, RatedPower, PVcase, SolarFarmer, Solargis, PlantPredict, HelioScope and SAM are trademarks of their respective owners. Heliosolve is not affiliated with, endorsed by or sponsored by any of them. Product names are used only to identify the products compared.