7 Solar Proposal Numbers You Should Never Re-Enter

A proposal coordinator changes a panel count in one screen and then spends the rest of the revision hunting for every place the old count survived. It may still appear in the system capacity, equipment table, production chart, bill of materials, price basis, financial scenario, and customer summary. The proposal looks polished because the wrong pages agree with themselves.

This is the real danger of re-entry. The visible typo is easy to catch. The plausible number copied from an older state can pass a quick review because it has the right shape. It lost the source, version, unit, scenario, owner, and dependency that would reveal why it no longer belongs.

“Never re-enter” does not mean no human may type a source value or correct a record. It means a number should enter the controlled project record once, then flow into dependent outputs. Corrections occur at the authoritative source through a documented change. A manual downstream override is an exception that must reconcile back to its source, not a faster normal workflow.

This article is not engineering, electrical, utility, tariff, incentive, tax, accounting, financing, contract, consumer-protection, or legal advice. Qualified owners must approve the real data model, permissions, calculations, integrations, customer disclosures, and proposal release process.

The data re-entry risk guide owns the general failure mechanism. This page owns the seven numeric families that deserve source-to-proposal lineage and the exception record that keeps a correction from becoming another detached value.

What does manual re-entry mean in a solar proposal workflow?

Manual re-entry occurs when a person reads a number from one record and types, pastes, rounds, or reformats it into another field that becomes a separate value. The second field can drift independently. A connected workflow references or regenerates from the authoritative source, preserves units and version, validates the transfer, and records any deliberate override.

Copy and paste still counts as re-entry when the receiving field has no live relationship to the source. So does typing a value from a PDF into a proposal template, rebuilding a total in a spreadsheet, or editing a chart label without updating the underlying model. The issue is not the keyboard. It is the independent state.

Define four roles for each material number:

NASA’s configuration-management guidance discusses configuration identification, change management, status accounting, and verification in NASA programs. It is not a solar proposal standard. The useful analogy is that a product’s state, changes, and verification need to remain visible rather than being reconstructed from whichever document is open.

NASA’s technical-data management guidance discusses planning how technical data are acquired, identified, accessed, managed, protected, and used in NASA work. Again, it does not govern a solar company. It helps frame the questions a number needs: where it came from, who can change it, which output uses it, and how the current state is known.

One source does not mean one unreviewed system

A source of truth can still be wrong, stale, incomplete, or unsuitable for the next decision. Connection reduces uncontrolled copies. It does not replace field validation, professional review, reconciliation, customer correction, or authority approval.

For every numeric family, distinguish source truth from release truth. The source record answers “what value is currently controlled here?” The release decision answers “may this value appear in this customer document for this purpose?” A proposal may need to hold a connected number because its evidence or review state is not ready.

Which seven numbers should never be re-entered manually?

Connect seven numeric families from their controlled sources: roof and site geometry, module quantity and DC capacity, shading and loss inputs, modeled energy yield, customer consumption and planned load, tariff and financial assumptions, and system price or payment figures. Treat each as a structured record with units, provenance, version, dependencies, review state, and release status.

1. Roof and site geometry

Lengths, areas, slopes, azimuths, heights, offsets, obstruction dimensions, and coordinate relationships can feed multiple design decisions. A proposal coordinator should not read a dimension from a drawing and type it into a customer document as a fresh fact.

The controlled geometry record needs the project and surface identity, value, unit, method, source, observation date, uncertainty or resolution where applicable, coordinate or scale relationship, and responsible reviewer. A modeled roof plane must remain distinguishable from a field measurement and a customer-stated dimension.

If the proposal needs a simplified display, format the connected value under a declared rounding rule. Do not round at the source and then round again in the proposal. The customer-facing format can change without creating a new technical value.

2. Module quantity and DC nameplate capacity

Module count and DC capacity should derive from the released layout and selected equipment record. Retyping either invites mismatches among the plan, equipment list, system summary, production model, price basis, and proposal narrative.

Store module model, applicable rating from the approved equipment source, quantity, layout version, status, and calculation relationship. Any displayed derived capacity needs a validated calculation with units. A layout change should regenerate the dependent capacity rather than rely on a coordinator to remember the multiplication.

Do not let the proposal become the authority for module count. If sales requests a different count, route a design change. When a qualified reviewer accepts the new layout, the proposal consumes that released state.

3. Shading and system-loss inputs

Shade factors, soiling assumptions, mismatch, wiring, availability, degradation, and other modeled losses can materially affect an energy result. The proposal should not contain an independently typed “loss percentage” whose model, scope, and period are unknown.

Connect each input to the model and scenario where it is used. Preserve whether it is measured, modeled, defaulted, estimated, customer-specific, or awaiting review. A label such as “system losses” is not enough when different tools or versions include different components.

The shading communication guide explains why a preliminary input should not be revealed as a surprise later. Connection helps the technical record and customer explanation refer to the same assumption.

4. Modeled annual and periodic energy yield

Annual production, monthly production, specific yield, and related modeled outputs should flow from the released energy model. A coordinator must not copy an annual result into a proposal, then leave it unchanged after the layout, equipment, shade, loss, weather, or model version changes.

The Department of Energy’s PV system design overview explains that a solar module is one part of a complete photovoltaic system with other technologies and components. It does not validate a specific project or guarantee production. Whatever approved model the company uses, the customer-facing value needs its model, input set, scenario, run time, version, unit, period, reviewer, and limitations.

Keep modeled output distinct from measured historical performance. A proposal for an unbuilt system presents a model, not an observation. If the current model is not released, the proposal should omit the value or use a visibly bounded scenario approved for that decision.

5. Customer consumption and planned-load inputs

Annual consumption, monthly usage, interval data, demand, and proposed load changes should connect to their utility or approved customer source. A number copied from one bill page can lose its service, meter, period, units, adjustments, and relationship to the intended property.

Record the source document or data export, customer and account scope, service identity, period coverage, unit, missing intervals, transformations, status, and reviewer. A customer statement about a future electric vehicle or heat pump is not a measured load. Store it as a scenario input with an evidence need.

The Department of Energy’s homeowner solar guide discusses energy efficiency, solar potential, needs, bids, financing, and working with an installer. It does not approve a consumption baseline or future-load assumption. The utility-bill reading guide covers the source questions that should accompany the number.

6. Tariff, escalation, incentive, and financial-model assumptions

Utility rates, rate structures, escalation assumptions, discount rates, incentive inputs, tax assumptions, financing terms, and analysis periods can change a financial scenario. They are also time-sensitive, jurisdiction-sensitive, customer-specific, and often subject to professional review.

Do not type a rate or incentive from memory into the proposal. Connect the approved assumption record with source, jurisdiction, effective date, eligibility boundary, expiry, units, scenario, owner, and review. If a value is illustrative, label it as illustrative and keep it outside a customer-specific conclusion.

No connected field makes tax, finance, accounting, utility, or incentive advice automatic. Qualified owners must establish what may be used and how it is disclosed. A stale connected value is still stale, which is why claim expiry and release review matter.

7. System price, discounts, financing, and payment figures

Base price, adders, discounts, taxes, deposits, financed amount, rate, term, payment, and contract totals should come from the approved commercial and financing records. Retyping a final price into the proposal can separate it from scope, equipment, branch, customer, approval, expiry, and contract terms.

Every displayed total needs a defined calculation or authoritative returned value. Keep price components and approvals visible. A discount request should create a controlled commercial change, not a hidden edit to the proposal total. Financing outputs should come from the responsible approved source and receive the required qualified review.

The customer document must match the current supported commercial record. An approved price source does not automatically approve the surrounding savings, affordability, urgency, eligibility, financing, or performance language. Each customer-facing claim needs its own evidence and responsible release decision.

How should numbers move from source records into the proposal?

Map each proposal number to one authoritative source, preserve its semantic meaning and unit, validate the connection, declare all dependencies, require the appropriate review, and generate the proposal from a released project state. When an upstream value changes, mark every dependent output stale until it is recomputed, reviewed, and accepted. Never let formatting create a second authority.

Use this controlled sequence:

1. Inventory every numeric field. Include prose, tables, charts, diagrams, equipment lists, summaries, footnotes, CTA calculators, and attachments.
2. Name the semantic field. “Annual energy” needs unit, period, scenario, model, and meaning, not merely a cell address.
3. Assign the authoritative source. Record its owner, id, access rule, update event, version, and expiry.
4. Map transformations. Document unit conversion, aggregation, rounding, calculation, formatting, and model dependencies.
5. Validate by script where arithmetic exists. Check typed units and dimensional compatibility before computing.
6. Declare stale conditions. A layout, equipment, usage, tariff, price, or finance change should invalidate named outputs automatically.
7. Require review at release. The receiving owner checks the number against its intended customer decision and risk class.
8. Generate and hash the document. Preserve the source versions, proposal version, release event, and exact artifact.
9. Monitor exceptions. Reconcile any downstream override back to the source before the next normal release.

Build a lineage matrix:

The proposal consistency checklist helps detect conflicts after a revision. A lineage map addresses the problem earlier by identifying which outputs should be regenerated when a source changes.

How should manual-entry exceptions be handled?

Treat every downstream manual entry as a controlled exception with a reason, evidence, old and new values, units, scope, editor, reviewer, affected dependencies, expiry, and reconciliation owner. Block release when the exception changes an unreviewed technical, financial, contractual, or customer claim. The exception closes only when the authoritative source and dependent outputs agree.

An integration may be unavailable. A legacy document may be the only source. A customer may correct a record during a meeting. None of those conditions requires pretending the retyped value is connected.

Use an exception ladder:

• Prefer a source correction. Update the authoritative record and regenerate the proposal.
• Use a bounded import. If a machine connection is unavailable, import with field mapping, units, source id, hash, validation, and reviewer evidence.
• Use controlled transcription. When transcription is unavoidable, require a second-source or double-entry comparison appropriate to risk, preserve the source, and mark the field imported.
• Use a proposal-only override only as an emergency exception. State why the source cannot be changed, block unintended reuse, assign reconciliation, and expire the override.
• Withhold the number when evidence is inadequate. A blank, bounded range, or held proposal is safer than an unsupported precise value.

Do not normalize overrides into a permanent shadow spreadsheet. Review exception patterns by source, field, interface, team, and dependency. The goal is not to blame the coordinator who caught the gap. It is to remove a recurring independent state.

NASA’s technical-assessment guidance discusses plans, measures, evidence, status, trends, variances, risks, and corrective actions in NASA technical work. It is not a solar quality standard. The process analogy is to compare the proposal field with a declared requirement and evidence state, then record the variance and corrective action rather than merely confirming that a value is present.

Validate meaning, not only equality

Two fields can both say 12,000 and still disagree. One may mean watts DC, another kilowatt-hours per year, another currency, and another annual consumption. Automated equality is not semantic validation.

The connection contract needs field id, type, unit, scale, period, scenario, jurisdiction where relevant, allowed rounding, null behavior, and version. Validate that the proposal label matches the connected meaning. A chart title can turn a correct source value into a misleading claim.

What copy-ready control keeps proposal numbers connected?

Use a numeric lineage and exception record for each material proposal field. It should identify the source, owner, unit, transformation, dependencies, stale events, reviewer, customer display, and release state. Add an exception section that preserves any manual override and its reconciliation. Review the record whenever a template, integration, model, product, or source changes.

Copy-ready solar proposal number-control record

Illustrative example, not a real project, customer, design, model, tariff, price, proposal, integration, or result. A layout revision changes the approved module quantity. The connected capacity and yield outputs become stale, but a legacy pricing sheet does not receive that event.

The proposal coordinator does not type the new count into the PDF and leave the other figures untouched. The team holds release, updates the authoritative layout, recomputes the validated capacity, reruns the approved yield model, and routes the commercial record for any required scope and price review.

If the legacy price must be transcribed, the record identifies its source, unit, scope, version, editor, comparison check, reviewer, and reconciliation owner. The customer receives no production, savings, price, or timeline promise until the responsible outputs are released.

SurgePV’s repository-verified scope includes 3D roof modeling, solar array layout, shading analysis, energy-yield modeling, financial modeling, electrical workflow support, bill-of-materials output, and proposal generation. Results depend on source data, assumptions, equipment models, configuration, integrations, and review.

SurgePV can support connected project and proposal workflows. It cannot verify every upstream record, decide engineering, establish a utility rate or incentive, approve financial or contract terms, guarantee integration behavior, or guarantee production, savings, price, approval, or customer outcomes.

The cleanest proposal is not the one with the fewest visible edits. It is the one where every material number can answer a simple challenge: show me the source, show me the version, show me what changes it, and show me who released it for this customer decision.

Frequently Asked Questions

Why is manual data re-entry risky in a solar proposal?

Re-entry separates a number from its source, units, version, assumptions, reviewer, and change history. A copied value can remain numerically plausible while referring to an older layout, different utility period, wrong equipment set, or superseded price. The control is not blind automation. It is connected data plus validation, approval, exception handling, and release evidence.

Does never re-enter mean a solar team cannot correct a number?

No. Correct the authoritative source through an approved change event, preserve the prior value, state the reason and evidence, obtain the required review, and regenerate dependent outputs. If an emergency proposal correction must occur downstream, label it an exception, block silent reuse, reconcile it upstream, and require receiver acceptance before release.

Which solar proposal number should be connected first?

Start with the number whose error has the widest customer and workflow consequence under the company’s own evidence. Often that is project identity, system capacity, modeled production, consumption, price, or a financial assumption. Map dependencies before prioritizing. Do not use a universal sequence without considering technical, financial, contractual, and jurisdictional risk.

Can proposal software guarantee that every number is correct?

No. Connected software can reduce unsupported transcription points and preserve source relationships, but correctness still depends on source data, units, assumptions, equipment models, configuration, integrations, permissions, review, and qualified decisions. Software cannot verify a utility record, approve engineering, establish a tariff or incentive, give financial advice, or guarantee production, savings, price, or approval.

How should a proposal display an important modeled number?

Show the value with its unit, meaning, model or source, relevant period, scenario, version, and material assumptions at the level a reviewer needs. Keep measured, customer-stated, source-recorded, calculated, and modeled values distinct. If the current evidence cannot support the number, omit it, present an explicitly bounded scenario, or hold the proposal for review.