Solar interconnection application checklist: build a utility-specific, version-controlled packet

Confirm the actual utility and project path

Identify the service location, utility, project reference, proposed system category and responsible applicant. Preserve the source for the technical project description, including the stated capacity basis where relevant. A general solar label is not enough to choose an application path.

Con Edison’s current public interconnection page routes applications according to project size, scope and compensation arrangement and uses PowerClerk for its specified application paths. That is a particular utility example reviewed on October 29, 2026, not a universal process for every utility or solar project.

Have the responsible utility or project professional confirm the applicable path and current instructions. Keep an unresolved category question visible rather than selecting a form because it is familiar. The administrative coordinator should not determine technical eligibility, tariff treatment or engineering requirements from a general checklist.

Sources: Con Edison: Applying for Distributed Generation Interconnection, current project paths and resources

Check source editions as well as the landing page

Record the exact instruction page, form or checklist, document edition where shown and date reviewed. A current landing page can still link older supporting material. Preserve the relationship and ask the appropriate owner to confirm how it applies before relying on a particular form or field list.

For example, the DG Documentation Checklist linked from Con Edison’s page identifies itself as Version 2, September 2017. It can provide historical mapping context, but its presence on the site should not be treated as proof that every detail is the current requirement for every application category.

Use the actual current utility process and system-specific sources for the packet. If documents conflict or a boundary category is unclear, preserve the question and responsible contact. Do not silently combine requirements from different editions, utility territories or project sizes into one supposedly mandatory list.

Sources: Con Edison DG Documentation Checklist, September 2017 version for source-edition context

Identify the applicant and document providers

Confirm who is authorized to prepare, review and submit the application under the actual utility process. Where an authorization or agreement is required, retain its actual source and review state in the approved controlled destination. Do not add a signature or imply representation that has not been established.

Map each required record to its provider: the customer, installer, responsible designer, equipment source or another actual party may supply different information. A coordinator can request a missing document without becoming the technical author or authorized signatory.

Keep private service and customer information appropriately controlled. A shared coordination sheet can use a project reference and document state without exposing account details or signed attachments broadly. Confirm who may view, transmit or act on each record through the actual project and utility process.

Create a stage-specific requirement index

Build the packet index from the applicable utility instructions, not a generic list copied from another project. For each item, record its source requirement, project scope, provider, required version or format, reviewer and current state. Keep initial application records separate from documents required at later stages.

Con Edison’s public small-project guidance identifies application, site-plan, diagram and equipment information in its particular process. Use that bounded example to understand why document coordination matters. The actual category, current instructions and responsible review determine the records needed for a specific project.

If an item is not applicable, retain the actual reviewed basis rather than simply leaving a blank field. If applicability is unresolved, keep it as a question. A shorter checklist is not necessarily complete, and a longer one can request unnecessary records from the wrong person.

Sources: Con Edison: Applying for Distributed Generation Interconnection, current project paths and resources

Reconcile the document set without designing the system

Track the current project description, equipment references, site plan and relevant technical drawings as required by the actual process. Identify their versions and responsible authors. The coordinator’s task is to expose a mismatch and obtain the correct reviewed source, not to repair an engineering drawing independently.

If equipment changes, identify the potentially affected application fields and supporting documents. Ask the responsible technical reviewer which records need revision. A newer equipment sheet should not silently update an older diagram or imply that the revised system has been reviewed.

Preserve superseded records and the reason for replacement. The final packet should identify the actual current set and its review source. A file named final or a recent modification timestamp is not sufficient evidence that the document is authorized for submission.

Worked example: six packet rows for a fictional small project

All project details, identifiers and states below are fictional. The exercise’s project description states an 8 kW AC inverter-based system in a Con Edison service area. The responsible project team has identified its application path; this is not a technical eligibility determination by the checklist.

The administrative routing source is confirmed, and a site-plan version has its required project review record. The customer-authorization record is received but awaiting its actual review. The application draft awaits the authorized applicant. Diagram v1 conflicts with the equipment record v2, and the equipment relationship needs the responsible technical reviewer’s confirmation.

The coordinator routes each gap to its actual source owner. No application has been submitted in this example, and none of the packet states establishes utility approval or permission to operate. The rows illustrate coordination categories, not a universal six-document requirement.

Ask for the specific missing source or decision

A useful request identifies the project, packet row, current document version, requirement source and precise gap. For P-85, ask the responsible technical author which reviewed diagram corresponds to equipment record v2. Do not ask the customer to make an engineering correction they do not own.

For P-82, identify the actual authorization review required by the process and its responsible person. A document received in a folder is different from a reviewed authorization. Keep the original source and any replacement relationship rather than generating a signature or representation statement to fill the gap.

If the recipient cannot supply the record, preserve the response and route the question through the responsible project process. Silence should remain an open state. A follow-up workflow should not invent a missing document, assume consent or convert a planned review into a completed event.

Review and preserve the actual submitted package

Before submission, the authorized applicant and relevant reviewers should identify the actual current packet version, required attachments and unresolved exceptions. Follow the utility’s real submission rules and permissions. A coordinator preparing the files should not assume authority to submit on another person’s behalf.

When an authorized submission occurs, retain its actual sender, channel, package version, timestamp basis and receipt or application reference. A prepared folder, draft portal entry or failed upload should not become a submitted date. If a required attachment is rejected, preserve the event and assign the next action.

Keep the submitted set available for later review. The team should be able to distinguish what it intended to send from what the utility actually received. A later replacement file needs its own relationship and source; it should not silently rewrite the original submission history.

If the portal creates a new reference for a correction or replacement, identify how the utility treats it: an amendment, a resubmission or a separate application can have different record relationships. Ask the authorized applicant to confirm the actual path rather than submitting duplicates to obtain another receipt. Preserve which attachments belong to each event and any open utility instruction. An internal package revision number and a utility application number serve different purposes; keep both traceable so the team can retrieve the actual submitted set.

Track completeness and technical responses distinctly

Record the utility’s actual response, application reference, scope, date basis and requested next action. A receipt can establish a transmission event while leaving completeness or technical review pending. Use the source wording rather than translating every portal status into approved.

If the utility asks for a correction, link it to the affected row and submitted version. Route the question to the actual applicant, technical author or other responsible source. A coordinator can manage the response queue without interpreting electrical requirements or supplying unsupported design answers.

Retain the correction, review and resubmission history. If a new equipment record affects more than one attachment, preserve the required current set and actual review. Do not infer acceptance because a file was uploaded successfully or no further message has yet arrived.

Keep later milestones and operating authorization separate

Identify the later agreements, inspections, testing, metering or other milestones required by the actual utility and project process. Record each requirement and responsible owner at the appropriate stage. The initial packet checklist should not imply that those later steps have already occurred.

Preserve the actual source for any authorization to install, connect or operate, according to the applicable process. An application receipt, local inspection or completed contractor record should not be substituted for a separate utility decision. This guide provides no electrical work or energization instructions.

If a project change affects a previously reviewed record or milestone, route it to the responsible parties and follow the actual change process. Keep the original decision and changed scope traceable. A generic complete status should not hide the question of which specific authorization applies to the current system.

Use the free interconnection-packet coordination register

The blank CSV includes project and utility, system-category source, applicable path and current instructions, packet row, provider, document version, review state, authorization reference, submitted-set relationship, receipt, utility response, later milestone and next action. Keep sensitive service and signed records in their approved controlled destination.

Enter P-81 through P-86 and test a revised diagram, a replacement authorization record and a utility correction request. Each update should preserve the original source and show the actual remaining review. No file upload should automatically create a utility approval or operating authorization.

Pilot one bounded application with the actual applicant and responsible technical reviewer. Ask another coordinator to identify the current packet, unresolved version question and next owner. Resolve unclear source editions and category assumptions before expanding follow-up across multiple utilities or project types.

Coordinate missing application records with Buildalytic

Buildalytic’s custom-workflow page describes requests, logged follow-up, waits and named approval steps. Bring a redacted utility requirement and one missing application record or version question to a demo. Ask how the request reaches the actual document provider and returns to the responsible reviewer.

Demonstrate an authorization awaiting review, a diagram-version question and a utility correction awaiting its source owner. Confirm supported document connections, permissions and applicant handoffs. The workflow should preserve the actual requirement and unresolved state rather than produce an engineering answer or assume authority to submit.

The useful demonstration shows traceable packet coordination and clear next actions. Utility eligibility, engineering decisions, signatures, submission authority and operating permission remain with the actual responsible parties. The fictional example does not claim faster interconnection, accepted applications or a verified customer result.

Sources: Buildalytic custom construction workflows