12 Common PVsyst Errors That Kill Project Bankability

A bankable PVsyst report is the single document lenders use to decide whether a solar project is worth financing. Get it wrong and the independent engineer (IE) sends it back — or worse, quietly flags it as unreliable. In fifteen years of solar engineering, the same twelve mistakes appear in report after report submitted by EPCs who know PVsyst well enough to run a simulation but not well enough to run a defensible one.

Direct answer. The 12 most common PVsyst errors that kill project bankability are: wrong soiling loss values, missing or incorrect horizon shading files, albedo set at default without site measurement, energy meter losses omitted, module degradation not annualised, incorrect DC/AC wiring losses, transposition model mismatch, IAM curve not set for bifacial modules, temperature model left at default, wake-effect underestimation for large arrays, use of low-resolution meteo data, and version-mismatch between bid and IFC simulations. Each error shifts P50 yield by 0.5–4%, compounding to a 6–12% swing that crosses most lender bankability thresholds.

This article dissects each error, explains why it matters to a lender or an independent engineer, and gives the exact PVsyst setting path you need to correct it. Whether you are preparing for a SECI auction submission or securing IREDA project finance, fixing these twelve points before submission is the difference between first-round approval and a 3-month correction cycle.

Error 1 — Soiling Loss Set to a Generic Default

Soiling loss is the single most site-specific input in a PVsyst model, yet it is the one most often left at the PVsyst software default. The default value of 3% annual soiling is calibrated for a temperate European climate. Indian sites — particularly in the GHI belt of Rajasthan, Gujarat, and Madhya Pradesh — see soiling rates of 8–14% during dry summer months and as low as 1–2% immediately after monsoon. The correct approach is to pull soiling data from a site-measurement campaign (minimum 4 weeks of irradiance logger + cleaned panel comparison) or from a validated third-party soiling database such as SolarGIS or DNI Agro.

In PVsyst, navigate to Project Settings → System Losses → Soiling Loss and enter monthly values, not a single annual average. A seasonal profile differentiates a bankable report from a template submission. Lenders specifically compare your soiling assumption against the SolarGIS seasonal dust model for your GPS coordinates — a 2% discrepancy will generate an IE comment; a 5% discrepancy generates an IE red flag.

The financial impact: on a 100 MW project with a P50 generation of 200 MUs/year, a 5% soiling underestimate translates to 10 MU/year of phantom generation — approximately ₹3.5 Cr/year at ₹3.5/kWh. Over a 25-year PPA, this is a present-value error of ₹40–55 Cr. No lender will accept that risk in their debt-service coverage ratio.

Error 2 — Horizon Shading File Missing or Wrong

Horizon shading — the long-range terrain and obstruction profile around the array — is mandatory for every ground-mount project above 1 MW. Most PVsyst submissions either omit the horizon file entirely or use a flat-horizon approximation that ignores hills, ridge lines, or adjacent built structures.

PVsyst accepts horizon profiles in three formats: manual entry, import from a .hor file, or direct pull from the integrated NASA SRTM terrain database. For utility-scale ground mounts, the SRTM-derived horizon is the minimum acceptable standard. For sites with complex terrain — valley floors, sites near Ghats, or hilltop installations in Himachal — a drone-surveyed or theodolite-measured horizon profile is required.

The horizon file affects both direct-beam loss (which shows up in the simulation as a distinct “far shading” loss line) and diffuse loss. On a 10 MW rooftop project in a dense urban area, neglecting the shading from adjacent buildings to the east and west can result in a 2–4% overestimation of annual yield. IE firms such as DNV GL, Bureau Veritas, and CRISIL always check the horizon file first in their technical due-diligence review.

Error 3 — Albedo Left at the Software Default (0.20)

Bifacial gain is now standard on 80%+ of utility-scale projects in India. But bifacial gain is only as accurate as the albedo value you feed into PVsyst. The software default is 0.20 — the global average for green vegetation. Actual site albedo for Indian conditions varies from 0.15 (dark laterite soil, Kerala/Karnataka) to 0.35 (dry sand, Rajasthan) to 0.55 (white concrete rooftop).

Errors in albedo directly scale bifacial gain. A 0.20 albedo assumption on a white-gravel-infill Rajasthan site understates bifacial gain by 2–3 percentage points. On a bifacial project with a nominal 6% bifacial gain, this is a 33–50% understatement of the bifacial contribution — material enough to move P50 by 1.5–2%.

The correction process:

1. Obtain a site albedometer reading from your irradiance monitoring station, or commission a 30-day albedo measurement campaign.
2. For sites without measurements, use the SolarGIS or Copernicus land-use albedo dataset for the GPS coordinates.
3. In PVsyst, enter the value under System → Array → Bifacial Module → Ground Reflectance.
4. Document the albedo source and measurement methodology in the PVsyst simulation report appendix — IE firms require this.

Error 4 — Energy Meter and Auxiliary Losses Omitted

This is the most mechanically simple error on this list and the one most frequently flagged by IEs. PVsyst calculates yield at the inverter AC output terminal by default. A lender’s bankability model — and therefore the project’s debt-service coverage ratio — is calculated at the metering point, which is downstream of:

• MV step-up transformer losses (typically 0.3–0.8%)
• HV interconnection cable losses (0.1–0.3% for 33 kV; 0.2–0.5% for 132 kV)
• Meter CT/PT accuracy losses (0.1%)
• Plant auxiliary consumption: SCADA servers, lighting, HVAC for inverter rooms, security (typically 0.2–0.5% of AC generation)

In PVsyst, these are entered under Losses → AC Losses → MV Line + Transformer + Auxiliary. The combined impact is typically 0.8–1.8% for a standard ground-mount with a single point of metering. Omitting it is not conservative — it is incorrect, and the IE will calculate the actual meter-point yield and disagree with your P50 figure.

Error 5 — Module Degradation Not Annualised Correctly

PVsyst reports a single-year yield figure unless you explicitly set up a multi-year degradation model. Many reports submitted to lenders show only Year 1 P50 yield without a 25-year degradation-adjusted P50 table. Lenders need the P50 yield profile for every year of the PPA/loan tenor to build the financial model. Submitting only Year 1 data requires the lender’s financial model team to apply their own degradation assumptions — which will always be more conservative than yours.

The correct approach: in PVsyst, use the Economic Simulation → Annual Degradation function to generate a year-by-year yield table. Use:

• First-year degradation: 2.0% (accounts for LID/LeTID for PERC; 1.0% for TOPCon)
• Subsequent years: 0.40%/year for Tier 1 modules with a linear power warranty
• Bifacial factor: apply a separate 0.05%/year additional degradation for the rear-side bifaciality ratio

The annualised P90 yield in Year 25 is the figure lenders use for debt sizing in tail-end stress tests. Getting this number right determines the project’s loan-to-value ratio.

Error 6 — DC and AC Wiring Losses Under-Specified

PVsyst allows you to enter wiring losses as a fixed percentage or compute them from cable lengths and cross-sections. The majority of bid-stage reports use fixed percentages because actual cable routing has not been designed. The error occurs when those percentages are copied from a smaller project without scaling for the actual inter-row cable runs of the new project.

On a 50 MW ground-mount with 200-metre string runs, a 4 mm² DC cable produces 3.8% DC wiring loss — more than double the 1.5% typically entered. The correction: use PVsyst’s cable calculator with the actual stringing layout from your CAD design. If the layout is not finalised, use 2.0% DC and 1.0% AC as conservative interim values and note them as provisional in the report.

Error 7 — Transposition Model Mismatch for High-Latitude or Tracker Sites

The transposition model converts horizontal irradiance from your meteo dataset into plane-of-array (POA) irradiance. PVsyst offers Perez, Hay-Davies, and Isotropic models. For most Indian ground-mount sites, Perez is the correct choice. For tracker sites, the choice interacts with the backtracking algorithm.

The common error: using the Isotropic transposition model on a tracker site. Isotropic is appropriate for overcast climates (north-western Europe) where diffuse radiation dominates. In India’s direct-normal-irradiance-dominant climate, Isotropic understates diffuse gain during morning and evening hours by 0.5–1.5%. For a single-axis tracker where morning and evening performance matters most, this error compounds.

In PVsyst, the model is set under Project → System → Transposition Model. Use Perez for all Indian utility-scale and tracker projects. For bifacial tracker projects, additionally enable the rear-side Perez model for rear-surface irradiance calculation.

Error 8 — IAM Curve Not Calibrated for Bifacial or AR-Coated Modules

The Incidence Angle Modifier (IAM) curve defines how module efficiency changes as the sun angle moves away from perpendicular. PVsyst defaults to an ASHRAE parameterisation with b0 = 0.05, which is calibrated for standard glass. Modern bifacial modules with anti-reflective (AR) coatings have a lower b0 — typically 0.025–0.035 — meaning they maintain higher efficiency at oblique incidence angles.

For a 100 MW project, 0.5% yield underestimation from incorrect IAM is approximately 1 MU/year — about ₹35 lakh annually. Cumulative over 25 years at a 7% discount rate, this is a ₹3.2 Cr NPV error in the financial model.

Error 9 — Temperature Model Left at Default NOCT

The thermal model governs how module temperature rises above ambient — directly determining power output reduction during hot hours. PVsyst offers NOCT (Nominal Operating Cell Temperature) and Faiman models. The Faiman model is more accurate for field conditions because it accounts for wind speed’s cooling effect.

Indian summer conditions — 42°C ambient, low wind, high GHI — produce cell temperatures of 70–75°C under NOCT model assumptions. The Faiman model with site-specific wind data from your meteo dataset produces 65–68°C, reflecting actual convective cooling from even light winds. The difference is 0.4–0.8% in annual yield.

The correction: obtain hourly wind speed data from your meteo file and activate the Faiman model under Advanced Simulation → Thermal Model → Faiman. Enter the U0 (heat transfer coefficient, constant component) and U1 (wind-dependent component) from the module manufacturer’s test data, or use the PVsyst library defaults for your module type.

Error 10 — Wake Effect Underestimation for Large Arrays

Near-shading (mutual shading between rows) is computed in PVsyst via the 3D shading scene. The error occurs in one of three forms:

1. Wrong pitch: the inter-row pitch in the 3D scene does not match the design drawings. A 5 cm discrepancy in pitch at 50 MW scale changes near-shading loss by 0.3–0.8%.
2. Missing electrical shading effect: PVsyst models “shadings according to module strings” which accounts for bypass diode activation. Many reports use the simpler “linear” shading model, which understates the electrical impact of partial shading by 0.5–1.5%.
3. Tracker rotation not activated: for single-axis tracker arrays, the backtracking algorithm in PVsyst must be activated to correctly model the rotation sweep and the resulting near-shading at low sun angles.

The fix: rebuild the 3D shading scene using coordinates exported from your PVsyst CAD or GIS layout, verify pitch against your structural BOQ, and use “shadings according to module strings” for the electrical effect.

Error 11 — Low-Resolution or Wrong-Year Meteo Data

The three most common meteo data errors:

Error	Impact	Correction
Using NASA/POWER free dataset instead of Solargis/Meteonorm	±5% GHI accuracy vs ±2% for premium datasets	Purchase Solargis PTM for the site coordinates
TMY based on 5-year historical record	Higher inter-annual variability → P90 spread widens	Use 20-year TMY minimum for lender submissions
Wrong GPS coordinates (nearest town vs actual site)	1–3% GHI error for sites near coast/mountains	Use exact GPS from site survey, not project brief
Using hourly data instead of sub-hourly for tracker sites	Under-captures transient cloud effects	Use 1-minute data for tracker simulations where available

The MNRE guidelines and all major IE firms now require Solargis or Meteonorm data for projects above 5 MW. NASA POWER data is acceptable for pre-feasibility but will be rejected at financial-close stage.

Error 12 — Version Mismatch Between Bid-Stage and IFC-Stage Simulations

This error is subtle and is the one most likely to surface during due diligence rather than at the IE review stage. PVsyst updates its internal algorithms, module database, and loss model defaults with each version release. A bid-stage simulation run in PVsyst 7.2 and an IFC-stage simulation run in PVsyst 7.4 will produce different yield numbers for the same inputs — sometimes by 0.5–1.5% — because of algorithm updates.

When a lender compares the bid-stage PVsyst report with the financial-close report and sees a yield number change, they ask for an explanation. If you cannot explain the delta line by line, they interpret it as a modelling error rather than a software update and request a full re-simulation.

The protocol: document the PVsyst version number on the cover page of every simulation. When updating from bid to IFC stage, produce a version-comparison table showing each major input change and its yield impact. This is standard practice at DNV GL and Bureau Veritas — Heaven Designs includes this comparison table in every bankable report deliverable.

The 12-Error PVsyst Bankability Audit — The BAPE Framework

The 12 errors above fall into four categories that form the BAPE Framework (Boundary, Atmosphere, Physics, Evidence) — a structured pre-submission audit process.

Apply BAPE as a checklist before every lender submission. Any “no” answer on the checklist is a rejection risk.

Error Impact Summary — Stacking the Losses

The twelve errors do not operate in isolation. They compound. A project with all twelve errors active can show a P50 overestimation of 8–15% compared to a correctly modelled simulation. The table below shows individual and combined effects:

Error	Typical P50 Impact	Lender Threshold
Soiling at default 3% (actual 8%)	+2.0–5.0%	> 1% triggers IE comment
Missing horizon file	+0.5–2.0%	> 0.5% triggers IE comment
Albedo at 0.20 (actual 0.35 bifacial site)	+1.5–3.0%	> 1% triggers IE comment
Meter losses omitted	+1.0–2.0%	Hard reject
No 25-year degradation table	Yield overstated Y25	Hard reject
DC wiring under-specified	+0.5–2.0%	> 1% triggers IE comment
Isotropic vs Perez transposition	+0.5–1.5%	> 0.5% triggers note
Default IAM on bifacial	+0.3–0.8%	Minor
NOCT vs Faiman thermal	+0.4–0.8%	Minor
Missing electrical shading effect	+0.5–2.0%	> 1% triggers IE comment
Low-resolution meteo data	±2–5%	Data source rejection
Version mismatch	+0.5–1.5%	Explanation required
Combined worst case	+8–15%	Full re-simulation required

A combined overestimation above 5% at P50 crosses the threshold used by DNV’s solar technical advisory team to require full re-simulation before they will sign an IE report. This is the definition of a bankability-killing error set.

How Heaven Designs Helps

Most EPC teams running PVsyst in-house hit 6–8 of these twelve errors on their first lender submission. The correction cycle — IE comment → internal revision → re-submission — adds 6–12 weeks to the project financing timeline and costs ₹5–15 lakh in consultant fees. Heaven Designs runs every bankable report through the BAPE framework before it leaves our desk.

• Bankable PVsyst Reports — full simulation, BAPE audit, 25-year table, IE-ready appendix pack.
• Solar Ground Mount Design — 3D shading scene, correct pitch, tracker activation, BOQ-calibrated cable losses.
• MW-Scale PMC — owner’s engineer review of third-party PVsyst reports before IREDA/PFC submission.
• STAAD Pro Reports — structural validation aligned with the same project parameters used in PVsyst.
• Download a sample deliverable — see what a corrected, IE-ready PVsyst report looks like.

Contact us to get a BAPE audit on your existing PVsyst simulation before the next IE review cycle. Turnaround: 5 business days.

FAQ

What is the most common reason a PVsyst report is rejected by an independent engineer?

The most common rejection reason is the omission of energy meter and auxiliary losses. IEs universally apply their bankability assessment at the metering point, not the inverter output. A simulation that terminates at the inverter overstates bankable yield by 1.5–3% — which is above the ±1% acceptance threshold used by DNV GL, Bureau Veritas, and CRISIL Infrastructure Advisory.

How do I know if my soiling loss values are site-specific?

Acceptable site-specific soiling data sources include: a minimum 4-week irradiance logger comparison between cleaned and uncleaned panels, a validated SolarGIS soiling model for the GPS coordinates, or an NSRDB aerosol optical depth dataset. A single annual percentage from a project template or software default is not acceptable for lender submissions above 5 MW.

Does the PVsyst version matter for bankable reports?

Yes. PVsyst updates its internal algorithms and module database with each release. A version change between bid-stage and IFC-stage simulations can shift P50 by 0.5–1.5% through algorithm updates alone. Document the version number on every report cover page and produce a version-comparison table when updating from one release to the next.

What albedo value should I use for a bifacial project in Rajasthan?

Rajasthan desert sites with natural sand and gravel ground cover typically use 0.25–0.35. Sites with white-gravel infill use 0.35–0.45. Sites with dry sand and light-coloured soil use 0.30–0.38. Commission a 30-day albedometer measurement for any project where bifacial gain contributes more than 3% to the P50 yield — at that level, albedo error becomes financially material.

How many internal links and IE comments are typical in a first-round PVsyst review?

A report with 3–4 of the errors described above typically receives 8–15 IE comments in the first round, requiring 3–6 weeks of revision. A report prepared using the BAPE framework typically receives 0–3 minor comments and clears the IE review in 1–2 weeks. The time difference translates directly to financial-close acceleration.

Should I use Perez or Hay-Davies transposition for tracker projects in India?

Use Perez for all Indian tracker projects. Hay-Davies performs similarly to Perez under high direct-normal irradiance but diverges by 0.5–1.0% in regions with significant circumsolar radiation — which includes much of the Indian GHI belt. Perez is the IEA PVPS recommended model for utility-scale bankable yield reports.

What is the correct first-year degradation rate for TOPCon modules in PVsyst?

TOPCon modules do not exhibit the initial LID/LeTID-induced first-year degradation characteristic of PERC modules. Use 0.5–0.8% first-year degradation for TOPCon and 0.30–0.35%/year linear degradation from Year 2. The NREL 2024 PV module reliability scorecard provides the most current field-validated degradation rates by technology type.

Can I use the NASA POWER free dataset for a 50 MW SECI tender submission?

No. MNRE guidelines and all major IE firms require Solargis Prospect TMY or Meteonorm 8.x data for projects above 5 MW. NASA POWER is acceptable for pre-feasibility screening only. The ±5% GHI accuracy of NASA POWER versus ±2% for Solargis is material at the bankability stage — the P90 uncertainty band widens proportionally to meteo data accuracy, and lenders use P90 for debt sizing. According to IRENA’s renewable power cost methodology, meteo data quality is a primary driver of yield uncertainty quantification in project finance.