G99 connection applications: the studies and evidence DNOs actually require

What a G99 connection application needs to succeed: the load flow, fault level and protection studies DNOs expect, why applications get delayed, and what good evidence looks like.

Most G99 connection applications are not refused because the project is unworkable. They stall because the supporting evidence does not let the network operator reach a decision without coming back with questions. Each round of questions costs weeks, and on a connection programme weeks translate directly into delayed energisation and delayed revenue.

This article sets out what a G99 application actually rests on: which studies the distribution network operator (DNO) expects, what the evidence needs to demonstrate, why applications get delayed or rejected, and what a package looks like when it satisfies the operator first time.

What G99 covers, and what it does not

Engineering Recommendation G99 governs the connection of generation to distribution networks in Great Britain, under the Distribution Code. It applies whether the network is operated by a DNO or an independent network operator (IDNO), and it covers conventional generation, renewables and battery energy storage.

G99 does not govern transmission-connected projects. A project connecting to the transmission system, or one large enough to fall under transmission arrangements, demonstrates compliance with the Grid Code instead. Applying G99 thinking to a transmission connection, or the reverse, is one of the quickest ways to lose credibility with a reviewer, so the first decision on any project is which framework actually applies.

Within G99, the depth of assessment scales with the size and type of the generator. A small connection is assessed against a limited set of requirements; a larger one attracts progressively more, including dynamic performance requirements such as fault ride through and frequency response. Scoping the application to the correct generator type at the outset avoids both under-evidencing and needless work.

The studies a G99 application rests on

A complete application is built on a coherent set of power system studies, not a collection of independent exercises. The core studies are:

  • Fault level assessment. Confirms that the additional fault infeed from the generation does not take switchgear, cables or other plant beyond their rated short-circuit withstand. A breach here can stop a connection outright until reinforcement is agreed.
  • Load flow and thermal assessment. Confirms the network can carry the export or import across its credible operating states without overloading circuits or transformers.
  • Voltage step change and flicker. Confirms that connecting, disconnecting and operating the generation keeps voltage changes within the limits the operator works to, typically assessed against the principles of EREC P28.
  • Harmonic assessment. For power-electronic connections such as inverters and battery storage, confirms harmonic emissions stay within the allocation the operator permits, assessed against EREC G5/5.
  • Protection coordination and settings. Confirms the protection will clear faults correctly, grade with the surrounding network, and meet the loss-of-mains and interface protection requirements G99 sets, with documented settings.

These studies interact. Fault level results feed protection coordination; the network model behind the load flow is the same model the harmonic and voltage work should reference. Studies prepared in isolation from one another, or from how the network is actually operated, are a common cause of connection delay.

What the DNO actually expects to see

A network operator is not looking for raw output. It is looking for evidence it can check against its own requirements and rely on. In practice that means:

  • A network model built on the operator’s own data and stated assumptions, so the reviewer can see the basis of every result rather than having to reverse-engineer it.
  • Results presented against the specific G99 requirements they demonstrate, so compliance is traceable clause by clause rather than asserted.
  • Protection settings and schedules that are complete and internally consistent with the scheme design.
  • Study reports written for a reviewer, with assumptions, limitations and the credible operating cases stated plainly.

The application form and single line diagram matter too, but they are the easy part. The evidence is where applications are won or lost.

Why G99 applications get delayed or rejected

The recurring causes are predictable, which is what makes them avoidable:

  • Studies that do not reflect the real network. Optimistic or generic assumptions about fault level, loading or operating configuration collapse under the operator’s review.
  • A missing or weak compliance thread. The studies exist, but nothing maps them to the G99 requirements, so the reviewer has to do that work and asks for clarification instead.
  • Protection that is designed after the studies rather than with them. Settings that do not grade, or interface protection that does not meet the requirement, send the whole package back.
  • Incomplete schedules. A gap in the protection settings, the plant data or the compliance evidence is enough to pause an otherwise sound application.
  • The wrong framework. Treating a transmission-connected project as a G99 connection, or vice versa, undermines confidence in everything else in the pack.

What good evidence looks like

A package that satisfies the operator first time tends to share the same characteristics. It is built on a single validated network model rather than several disconnected ones. Its assumptions are explicit and defensible against the operator’s data. Every study is tied back to the requirement it demonstrates, so compliance can be read rather than inferred. Protection is designed from the network behaviour required, not from a preferred relay catalogue, and its settings are documented. And where the operator may want to review or reuse the analysis, native study models can be supplied on request.

None of this is exotic. It is the difference between a pack assembled to tick boxes and one assembled to answer the question the reviewer is actually asking.

Where digital engineering reduces programme risk

The authority in a connection application comes from the engineering, not from tooling. But how the analysis is produced does affect programme risk. A single, well-structured network model that feeds fault level, load flow, voltage and protection work removes the inconsistencies that appear when those studies are built separately. Automating the repetitive parts of study production and reporting reduces transcription errors and frees senior time for the judgement calls. Structured, version-controlled data means the settings in the report match the settings in the scheme, every time.

The benefit is not novelty. It is fewer rounds of comment, faster turnaround and a compliance thread that holds together, which is exactly what protects an energisation date.

When to bring in a consultancy

The right time to get connection support involved is before the application is drafted, not after the first round of comments arrives. Framing the study scope correctly, building the model on the operator’s data and preparing the compliance evidence alongside the design is far cheaper than reworking a rejected pack under programme pressure.

If you are preparing a G99 connection, or want an existing application reviewed before it goes in, tell us the project: the connection voltage, the generation type and capacity, and the network operator. A specialist engineer will reply with a clear view of the studies and evidence it needs.

Working on a connection or a study like this?

Tell us the project: connection voltage, generation type and capacity, and the network operator. A specialist engineer will reply with a clear view of the studies it needs.

Speak to a power engineering specialist