Solar Proposal Version Control: How to Keep Customer Documents Current

A solar proposal should make a decision easier, not force the buyer to guess which attachment is current. Yet most proposal confusion starts with an ordinary event: a new bill arrives, the layout changes, a battery option is added, an equipment choice changes, or a customer asks for a different financial scenario. If the team sends a fresh PDF without explaining the effect, two apparently credible documents can compete in the buyer’s inbox.

This is a desk-research guide for installers and EPCs. It explains document control for customer-facing proposals. It does not replace contract review, consumer-protection obligations, local requirements, utility conditions, engineering judgment, or the project’s formal change process. The point is operational clarity: preserve the path from current project information to the document the customer is reviewing.

A Proposal Is a Snapshot of a Project State

A proposal combines several kinds of information: system scope, layout, equipment, modeled production, financial assumptions, exclusions, process steps, and visual explanation. Each item may come from a different source. The document can be excellent at the moment it is created and still become misleading after a material input changes.

This is why filename-only control is weak. “Final v2” tells a customer neither what changed nor whether the original was withdrawn. A proper version record answers four questions: which project state produced this document, why was it issued, who received it, and what action should the recipient take next?

The U.S. Department of Energy Solar Energy Technologies Office supplies public background on solar technology and adoption. It does not verify a project proposal. Project figures and scope need their own dated inputs, review record, and customer communication trail.

Use a Version Identifier That Humans Can Read

A useful identifier does not need complex software. It needs to be consistent. Combine a project reference, a customer-facing revision number, and an issue date when appropriate. Avoid numbers that silently reset when a sales person creates a new email thread.

The identifier alone does not solve the problem. It creates a reference point for the explanation. A customer should not have to compare tables to learn that Revision 3 reflects a smaller array, different tariff assumption, or changed equipment option.

Categorize the Reason Before Revising the File

Not every change has the same customer impact. Categorizing it helps the team decide whether a revision is editorial, informational, technical, commercial, or contractual.

Editorial Corrections

Examples include spelling, formatting, contact information, or a broken link. These may need a corrected copy but usually do not alter the project decision. Tell the recipient that the correction is editorial so they do not assume the system changed.

Updated Evidence

A new electricity bill, interval data file, survey finding, equipment data sheet, or utility response can change an assumption. The revised proposal should say which evidence changed and whether it altered the visible scenario. This protects the team from presenting an old calculation as though it were based on the latest record.

Scope or Technical Revision

An array change, battery option, inverter selection, roof limitation, or different configuration may affect modeled generation, price, installation approach, and permits. The document should not merely replace a page. It should tell the buyer that the configuration changed and direct the team to explain the difference.

Commercial or Process Revision

A revised price, financing term, stated validity period, incentive assumption, schedule discussion, or excluded work needs care. Contract terms and applicable law determine the effect. The operational record should identify whether the proposal is an updated option, an offer subject to defined conditions, or an input to a separate agreement process.

Write a Buyer-Facing Change Summary

The change summary is the most useful part of version control. It should appear in the delivery message or proposal cover, not only in a private internal note. Use short, concrete language.

For instance: “This revision updates the modeled scenario using the electricity information supplied on August 18, 2026. The layout and equipment option remain unchanged.” Or: “This revision presents the battery option you requested. Backup duration remains dependent on defined loads, operating conditions, and final configuration.” These statements describe what happened without guaranteeing an outcome.

Avoid vague language such as “updated for accuracy.” It creates a question the customer may not ask: was the previous proposal inaccurate? Name the item that changed. If the team cannot explain the change clearly, it may not yet understand whether a customer revision should be issued.

NREL’s PV research material can inform general technical context. It is not a substitute for telling the customer which specific data or design choice changed in their own document.

Keep Assumptions Visible Across Versions

Proposals often include numbers that are sensitive to inputs: energy scenario, tariff, consumption, financing, equipment configuration, and project timing. A revision should carry forward relevant assumptions or state when an assumption has changed. Do not let a new cover page make older caveats disappear.

Create an assumption register with five fields: description, source, date, status, and output affected. A status can be confirmed, estimated for scenario planning, or pending verification. This register need not be customer-facing in full, but the customer-facing proposal should accurately represent the assumptions that matter to the decision.

Generation & Financial Tool supports scenario-based energy and financial analysis in SurgePV. Its output is only as dependable as the inputs and assumptions recorded with the project. A version-control process should connect a revised proposal to the scenario used, rather than treating a calculated figure as timeless.

Decide What Happens to Earlier Copies

Older proposals are not automatically wrong. They may show an alternative that the buyer still wants to compare, or they may have been incorporated into a separate contractual process. The team needs an explicit status for each older version:

• Superseded: no longer represents the current option; direct the recipient to the newer copy.
• Alternative retained: remains a valid comparison scenario, with its version and assumptions clearly identified.
• Historical record: kept for traceability but not for active decision-making.
• Governing document identified elsewhere: a separate agreement or approved change process determines the operative scope.

The last category deserves legal and commercial care. A blog cannot determine which document controls a particular transaction. The operational benefit is that the sales, design, and project teams do not use the word “final” casually when the governing status is unknown.

Control Delivery, Not Just Creation

A proposal is not delivered merely because a file exists. Record who received it, how it was sent, and what next conversation was agreed. Shared inboxes, forwarded links, multiple decision makers, and revised attachments can otherwise create conflicting evidence about what the customer saw.

When a revision is material, avoid assuming that a sent email resolves the conversation. Ask whether the buyer wants a review of the changed assumptions, configuration, or option. This is especially useful for commercial stakeholders who may need a finance, facilities, procurement, or executive review. The handoff may be a meeting, a written comparison, or a request for missing information—but it should be explicit.

Solar Proposals is SurgePV’s product area for creating branded client-ready proposals. The platform can help teams bring design output into a presentable document. A reliable delivery process still needs the project team to identify the current version and communicate its status to the buyer.

Prevent Revision Loops Between Sales and Design

Revision control becomes difficult when a customer request comes back as a vague message: “Can we make it bigger?” Sales should record what the customer means, which proposal they reviewed, what decision they are trying to make, and whether the request concerns system size, appearance, backup, price, financing, timing, or another issue. Design can then decide what analysis or evidence is required.

Do not edit a design-derived figure directly in a proposal to answer the request quickly. That creates an undocumented divergence. Route the requested change to the appropriate design, commercial, or qualified review path, then issue a version that accurately reflects the resolved project state.

Use a Proposal Register During Weekly Review

For active projects, a lightweight register can prevent document confusion. Review only records that have an overdue next action, a customer request awaiting a revision, a material assumption that has changed, or competing versions in circulation. The register should show current version, delivery status, customer question, owner, and next action.

The goal is not surveillance or an overly elaborate sales process. It is to stop a customer from making a decision on a proposal the project team no longer recognizes. If a revision is taking longer because a site condition or utility answer is open, record that fact and explain it honestly.

Clear ownership prevents the register from becoming a forgotten archive.

Practical Next Steps

1. Add a readable revision label and issue date to every customer proposal.
2. Include a short change summary whenever a material input or scope changes.
3. Mark earlier copies superseded, retained as alternatives, or historical in the project register.

Frequently Asked Questions

What should change when a solar proposal is revised?

The revision should identify the new version, why it changed, the design or financial assumptions affected, who received it, and whether an earlier copy is superseded or retained as an alternative. The team should also decide whether the customer needs a review conversation.

Does a revised proposal replace the contract?

Not automatically. A proposal, agreement, and change order can have different legal and commercial roles. Use the applicable contract process and identify which document governs rather than assuming that the newest PDF controls the transaction.

How long should old solar proposals be kept?

Retention obligations depend on the contract, jurisdiction, company policy, customer requirements, and applicable rules. At minimum, retain enough project history for the team to identify what was issued, what changed, and which version was current at each decision point.