Every ASTM E2848 PV capacity test ends the same way: with a report. It is the artifact that the owner, the EPC, and the lender's independent engineer actually see — and if the result is contested, it is the document every number gets challenged against. Yet the standard itself defines the test method, not the report format, so report quality varies enormously in practice. Some are five-line pass/fail memos; others are defensible engineering documents.
This article walks through a complete sample report section by section and explains what belongs in each part — and what an experienced reviewer will look for.
Download the sample report (PDF) — a complete seven-page capacity test report for a fictional 357 kW rooftop PV system with bifacial modules, generated with HelioTest. It is free to download and share, with no sign-up required.
The sample report: summary page and the capacity test result — a failing test, on purpose.
Why the Sample Shows a Failing Test
The sample reports a capacity ratio of 91.1% against a passing threshold of 97% (a 3% tolerance). That is deliberate.
Passing reports get filed away. Failing reports get audited — by the EPC disputing liquidated damages, by the owner's engineer, by everyone with money at stake. A report only proves its worth when the result is bad news, because that is when every filtering decision, every excluded data point, and every regression coefficient will be questioned. If your report can defend a failing result, it can defend anything.
For what happens contractually and technically after a failed test, see our guide on what happens when a solar system fails its capacity test.
Section 1: Summary — the Only Page Most People Read
Stakeholders skim. The first page must state the result completely: test period, measured capacity, target capacity, capacity ratio, tolerance, and the pass/fail verdict — with no need to read further. The sample also includes a free-text remarks field, which is the right place for context that numbers cannot carry: sensor observations, unusual weather during the test window, or agreed deviations from the test plan.
A summary that buries the verdict, or states it without the tolerance that defines it, forces every reader into the appendices. Reviewers notice.
Section 2: System Configuration — What Exactly Was Tested
The sample documents the array (1,020 modules at 350 W STC, 357 kW DC, 10° tilt, 175° azimuth, bifacial) and — just as important — the sensor inventory with data tags: which physical instrument maps to which column in the raw data (wss_950_poa for front plane-of-array irradiance, wss_951_bpoa for rear, and so on).
The data tags are what make the report traceable. When a reviewer asks "which irradiance signal did you regress against?", the answer must be checkable against the raw files, not reconstructed from memory six months later.
Section 3: Input Data — Provenance
Two datasets feed an E2848 test, and the report names both source files explicitly:
- Measured data: seven days at 5-minute resolution, with each column's role and unit tabulated.
- Modeled data: the PVsyst simulation as raw hourly values — the full 8760, not the summary report. This is a common stumbling block; the test requires the model's hourly output, and a report that cannot name its model file invites the question of whether the target capacity is reproducible at all.
Section 4: Data Processing and Filtering — Where Tests Are Won and Lost
Filtering is the most consequential and most disputed stage of an E2848 test, and it is where thin reports fail their authors. The sample handles it in two parts.
First, the filtering parameters are stated up front: irradiance window of 400–1050 W/m², shading loss threshold, clipping threshold, the ASTM E2939 percentile method for reporting conditions, and the ±20% irradiance band around the reporting condition. Whether these came from the contract's test protocol or from method defaults, they must be in the report — a filter parameter that appears nowhere is a filter parameter that gets challenged.
Second — and this is the part most reports omit — a filtering waterfall: every step, in order, with the number of points surviving each one. For the measured data in the sample:
| # | Filter | Points after | Removed |
|---|---|---|---|
| 1 | Shade-free hours | 427 | −1,529 |
| 2 | Irradiance range | 427 | 0 |
| 3 | Remove missing data | 427 | 0 |
| 4 | System-level clipping | 427 | 0 |
| 5 | Remove outliers | 409 | −18 |
| 6 | Irradiance around reporting condition | 343 | −66 |
The same table exists for the modeled data (8,760 hourly points down to 125). Every removed point is accounted for, which means a reviewer can audit the data reduction instead of taking it on faith. The report also states the standard's floor explicitly: a minimum of 750 minutes of valid data — 50 points at the standard's 15-minute cadence — must survive filtering for the test to be valid.
Section 5: Reporting Conditions — the ASTM E2939 Link
The capacity ratio is evaluated at one specific operating point: the reporting conditions. The sample derives them from the modeled data per ASTM E2939 — POA irradiance as the 60th percentile of the filtered values (813 W/m² here), with temperature and wind speed as arithmetic means.
This choice matters more than it looks: both the target and the measured capacity are computed at these conditions, so the method and the resulting values must both be documented. Two testers using different percentiles on the same site will report different capacities — legitimately — and only the documentation makes the results comparable.
Section 6: Regression Analysis — Coefficients and P-Values
Both datasets are fitted with the ASTM E2848 power equation:
where E is POA irradiance, T is ambient temperature, and v is wind speed.
The sample publishes the fitted coefficients for both the model and the measured regression, along with the p-value of every term. Publishing p-values is not decoration: a term with p > 0.05 is a flag that the regression may be over-specified for the conditions captured in the test window. And publishing coefficients side by side lets a reviewer spot physical inconsistencies — in the sample, the temperature interaction term changes sign between the model fit and the measured fit, which is exactly the kind of detail a diligent independent engineer will ask about. A report that shows only the final capacity number makes that scrutiny impossible — and its absence is itself a finding.
Section 7: Results — the Arithmetic in the Open
The final numbers are computed transparently: each regression is evaluated at the reporting conditions, yielding a target capacity of 315.1 kW and a measured capacity of 286.9 kW, hence:
Against a tolerance band of 97–103%, the test fails. Note the band's upper bound: exceeding it does not fail the test, but the report flags it as informational — a capacity ratio well above 100% usually indicates a measurement or model problem, not a heroic plant.
Section 8: Charts — the Visual Audit
Two plots close the report, and each answers a reviewer question:
- Power vs. irradiance, with the filtered model and measured points and both regression lines. Tight scatter around the fits confirms the filtering did its job; a fan-shaped cloud means disturbed data survived.
- Retained measured points over the test period, colored by irradiance. This makes gaps visible — you can see a partly cloudy day contributing almost nothing — and shows at a glance whether the qualifying data is spread across the window or bunched into two afternoons.
What Reviewers Actually Challenge
Across the reports we have seen contested, the recurring questions map directly to the sections above:
- Filter provenance — were the thresholds contractual, or chosen after seeing the data?
- Reporting condition selection — which method, which percentile, derived from which dataset?
- Data sufficiency — how many points survived, versus the 750-minute minimum?
- Regression validity — are all terms significant, and do the coefficients make physical sense?
- Traceability — can every number be followed back to a named file and column?
A report that answers all five before they are asked is what "defensible" means in practice.
How This Sample Was Generated
The sample was not assembled by hand. HelioTest generates the report directly from the analysis: the filtering waterfall, regression tables, and charts come from the same computation that produced the result, so the document and the analysis cannot drift apart. The demo data behind this sample is preloaded in the HelioTest sandbox — the Try Sandbox button in the navigation opens it with no sign-up — where you can inspect this exact test run, change the filtering parameters, and regenerate the report yourself.
Download the sample report (PDF)
Related Articles
Peter is an engineer with a PhD in renewable energy management and over a decade of experience in software development for renewable energy applications. He built HelioTest to replace the fragile spreadsheet workflows he encountered across dozens of ASTM E2848 capacity tests.
