NERC GADS Solar Reporting: The Complete 2026 Guide
Thresholds, deadlines, cause codes, contributing operating conditions — and the classification judgment calls that decide whether your filing survives a Regional Entity's attention. NERC GADS reporting is mandatory for solar plants of 20 MW or more operating in the North American bulk power system. Operators must file performance and event data quarterly, within 45 days of quarter end — inverter-group performance records, plant event records with cause codes, and contributing operating conditions. Most compliance findings trace to event misclassification and hour-balance errors, not missed deadlines.
GADS for solar is no longer new — but the plants crossing the 20 MW threshold every quarter are new to it, and the institutional knowledge accumulated for conventional and wind generation does not transfer cleanly. Solar GADS has its own performance-record structure, its own hour-balance logic built around Active Solar Inverter Hours, its own event-classification traps, and its own data-quality validation gauntlet at the portal. This guide is the reference we wish every reporting engineer had before their first filing — and the process argument we make to every compliance team still running the quarter out of spreadsheets.
Who must report, and by when?
Any solar plant with 20 MW or more of installed capacity connected to the North American bulk power system must report to NERC's Generating Availability Data System. The cadence is quarterly, with a 45-day filing window after quarter end. The obligation covers both performance data — how the plant and its inverter groups produced — and event data: what went wrong, why, for how long, and at what energy cost. Miss the window, file incomplete data, or fail the portal's validation checks, and you are having a conversation with your Regional Entity — one that is documented, and one that colors every subsequent audit interaction. The plants that struggle are rarely careless; they are under-instrumented for the task. What we hear consistently from operators doing this manually: the quarterly cycle consumes three to four days of their best compliance engineer's time — pulling SCADA exports, computing performance fields in spreadsheets, scanning telemetry to find event boundaries, and cross-referencing the Data Reporting Instructions to pick cause codes with no analysis behind the selection.
What actually gets filed?
Three artifact families. First, Inverter Group Performance Records: the full set of monthly performance fields per inverter group — on the order of 28 fields covering generation, capacity, irradiance, and the inverter-hour balance, in which every Active Solar Inverter Hour must be allocated to a bucket (service hours, forced outage, maintenance, planned outage, resource unavailability) and the buckets must reconcile exactly to the group total. If the balance does not close, NERC's data-quality checks will flag it. Second, Plant Event Records: every reportable event with its cause code from the DRI, its event type (forced, maintenance, planned), its Contributing Operating Condition where warranted, its duration, and its MWh loss — with a narrative description that will be read, possibly years later, by someone deciding whether your classification was defensible. Third, the derived performance factors computed per the DRI's formulas: equipment availability factor, equipment net capacity factor, forced outage rates, performance index. Co-located battery systems file separately through the Energy Storage Performance Record, covering charge and discharge energy, availability, and outage hours.
Where do filings actually go wrong?
Rarely on deadlines. The findings cluster in four places. Hour balances that do not close — usually a manually reclassified maintenance window that never made it back into the ledger. MWh loss figures that do not reconcile with the forced-outage hours they sit beside — usually spreadsheet drift across versions. Cause codes chosen from the DRI list by resemblance rather than analysis. And Contributing Operating Conditions that are missing where weather genuinely contributed, or present where it could not have — both directions are findable in review, because a defensive COC is itself a flag.
A fault code names a symptom; the GADS cause code must name a root cause; and the distance between the two is analysis. An inverter fleet reports an over-temperature fault — but if the ambient was mild, the skies clear, and inspection finds the cooling paths clean, the thermistors failed, not the thermal management. The correct classification is the sensors and instrumentation family: a different code, a different narrative, a different maintenance conversation.
Code the symptom instead of the cause and you have filed a misclassification that a Regional Entity, or your own warranty counsel, may eventually read closely. The pattern underneath all four failure modes is the same: decisions made weeks after the event, from memory, with no analysis attached. When a Regional Entity asks — and on any material event, eventually one does — 'why was this coded this way?', the only durable answer is a documented one: the telemetry read, the weather at the event window, the reasoning, and who made the call.
| Failure mode | Root cause | Defense |
|---|---|---|
| Hour balance does not close | Manual bucket reclassification | Automated reconciliation on every computation run |
| MWh loss inconsistent with outage hours | Spreadsheet drift across versions | Loss derived from the same telemetry as the hours |
| Wrong cause code | Fault-code resemblance, no root-cause analysis | Classification with documented reasoning per event |
| COC wrong or missing | Judgment call from memory | Weather data pulled for the actual event window |
How Ellume BRIDGE runs the quarter
Human authority, machine documentation. The reviewer approves, overrides, or answers — and every action lands in the Human-in-the-Loop Audit Trail: what the AI classified, what the human decided, and exactly why. High-confidence routine events auto-classify; everything else waits for a person. When a Regional Entity calls months later, the answer to 'why was this event coded this way' is an export, not an archaeology project.
- •Every GADS performance field is computed directly from 15-minute telemetry — no transcription step, no spreadsheet version to drift.
- •Events are detected from data rather than recalled from logs, with boundaries, duration, and MWh loss derived from the same interval series that produced the hour buckets.
- •Each classification carries its evidence: the fault records, the weather at the event window, and the precedent that supports the chosen DRI code.
- •Before anything is filed, BRIDGE runs the DRI's data-quality validation rules — 29 checks covering hour-bucket balances, MWh-loss consistency, field completeness, date validity, and capacity consistency — as a precondition to generating submission files, so the NERC portal becomes a formality rather than a discovery process.
The quarter, after: on a representative Q2, two inverter groups computed, four events detected and classified, two auto-classified, two routed for human review, 29 of 29 validation rules passing, and the submission package assembled before the quarter closed. What used to take three to four days of a senior compliance engineer now takes the hours needed to make informed classification decisions — which was always the only part of the job that required a human.
What does a defensible process look like — with or without us?
Four properties, stated tool-neutrally, because they are the standard whether or not you buy anything from Ellume. Performance fields computed from telemetry, not transcribed into spreadsheets. Events detected from data, not recalled from logs. Every classification carrying its evidence — fault records, weather at the window, precedent — and every human override recorded with author and rationale. And validation run against the DRI data-quality rules before submission, not discovered at the portal. Teams with that process spend hours per quarter on GADS and walk into audits with an export. Teams without it spend days per quarter and carry classification risk into every filing they have ever made.
Frequently Asked Questions
- Does the 20 MW threshold apply per plant or per site?
- It applies to the installed capacity of the plant as registered with NERC. Operators with phased builds should confirm registration treatment before a later phase pushes aggregate capacity over the threshold mid-year.
- What is a Contributing Operating Condition (COC)?
- A COC records an external condition — typically weather — that contributed to an event without being its root cause. It must be included where warranted and omitted where not; both errors are findable, and the defensible determination is one made with meteorological data from the actual event window.
- How is MWh loss for an event calculated?
- From the telemetry: the gap between what the affected capacity would have produced across the event window and what it did produce, consistent with the forced-outage hours recorded for the same interval. Loss figures that do not reconcile with their hours are among the most common data-quality flags.
- Are co-located battery systems reported in GADS?
- Energy storage reports through its own performance-record structure — the Energy Storage Performance Record — covering charge/discharge MWh, availability, and outage hours, filed separately from the solar inverter groups. BRIDGE handles the BESS group alongside the solar groups in the same pipeline.
- Can filings be revised after submission?
- Resubmission is possible, but a pattern of revisions is itself a data-quality signal to your Regional Entity. The goal is a filing that is right the first time, with the analysis on record to defend it later.
- What should we do the quarter we cross 20 MW?
- Start the telemetry pipeline and event-classification discipline at least one quarter before the obligation begins. The first filing is the one that sets your Regional Entity's expectations, and retrofitting event records from memory is where first filings go wrong.
