NEM connection-queue reality check: what the AEMO register actually tells you
Treating the AEMO connection register as a proxy for project reality is a common mistake. A guide to reading it the way our red-flag engine does.
The AEMO connection register is one of the most-cited data sources in Australian renewables and one of the most misused. If your screening process reads it at face value (one row per project, connection status equals truth) you will overstate your investable pipeline by somewhere between 20 and 40 percent.
This is not a criticism of AEMO. The register is doing exactly what it is designed to do: reflect the formal state of every connection application in a transparent, auditable way. The problem is that the formal state and the commercial state are two different things.
Three gaps between the register and project reality
1. Stuck-but-not-withdrawn projects
A project can sit at 'connection enquiry' or 'connection application' for two years while the developer quietly walks away from the opportunity, without formally withdrawing. The register still shows the MW and MWh figures. A naive pipeline tool treats the capacity as in-flight. An experienced analyst cross-references the milestone dates, the developer's other activity, and the TNSP-side signals to tell whether the project is still alive.
2. Re-scoped capacity
MW and MWh numbers change mid-flight. A 200 MW / 400 MWh project might file as a 300 MW / 600 MWh two-stage scheme, drop stage two, shave capacity during the 5.3.4A process, and end up as 150 MW / 300 MWh at financial close. Each state appears in the register at different times. Read only the headline figure and you will double-count capacity that was re-scoped, not added.
3. Ownership churn
The SPV name on the register often lags the real owner by six to twelve months. An investor who bought the project in 2024 Q4 might not appear as the registered proponent until 2025 Q3. If your pipeline view keys on registered proponent, you will systematically misattribute deals.
What a good read looks like
Our red-flag engine treats the AEMO register as one signal among several, not as truth. Specifically we cross-reference it against:
- TNSP-side milestone dates, whether anyone has actually commissioned studies the developer would need to advance
- Published generator information and MLF history, whether the project's eventual MLF is trending in a way that sustains IRR
- Corporate filings and published transactions, whether the current registered proponent still owns the SPV
- Public statements, tender responses, and grid code compliance filings, the operational signals of a project that is actually being built
None of this is exotic. Every good NEM analyst does it on an ad-hoc basis. The point is that it should be systematic and exposed in the pipeline tool, not dug out by hand every time the analyst looks at a project.
This is one of the half-dozen screens our engine runs on every project in every client's coverage. A public version of the full methodology will appear in the BESS DD Methodology v1 paper, in preparation.