7 Numbers That Should Never Be Re-Entered Manually Into a Solar Proposal

Illustrative scenario, not a customer case: A proposal coordinator changes a panel count on one screen. Then the coordinator spends the rest of the revision hunting for every place the old count survived. It may still show up in the system capacity, equipment table, and production chart. It may also show up in the bill of materials (the parts list), price basis, financial scenario, and customer summary. The proposal looks polished because the wrong pages agree with each other.

Re-entry can hide a mismatch. You can easily catch a visible typo. A believable number copied from an older state can pass a quick review because it looks right. It lost the source, version, unit, scenario, owner, and dependency that would show why it no longer belongs.

“Never re-enter” does not mean that no person may type a source value or fix a record. It means a number should enter the controlled project record once. Then it should flow into the outputs that depend on it. You make corrections at the official source (the one record that owns the value) through a documented change. A manual override downstream is an exception. It must be reconciled back to its source. It is not a faster normal workflow.

Use this record-control framework with your team’s own review rules.

For the broader workflow problem, read the data re-entry risk guide. Writing down which record owns each number is also part of how a team can standardize solar design. Use the seven families of numbers below to map proposal fields to their sources and to record exceptions.

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

Manual re-entry happens when a person reads a number from one record and types, pastes, rounds, or reformats it into another field. That field then becomes a separate value. The second field can drift on its own. A connected workflow refers to the official source, or regenerates from it. It keeps units and version, checks the transfer, and records any deliberate override.

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

Define four roles for each material number:

NASA’s configuration-management guidance lists five elements. They are planning and management, configuration identification, and change management. The last two are status accounting and verification. The habit applies to proposals. Keep a number’s state, its changes and its checks in view. Do not rebuild them from whichever document is open.

NASA’s technical-data management guidance covers how technical data are identified, controlled and protected. It also covers how the data reach the people who use them. The same questions apply to a proposal number. Where did it come from? Who can change it? Which output uses it? How do you know its current state?

One source does not mean one unreviewed system

A source of truth can still be wrong, out of date, incomplete, or a poor fit for the next decision. A connection cuts the number of uncontrolled copies. It does not replace field checks or professional review. It does not replace reconciliation, customer correction, or approval by the authority.

For every family of numbers, keep source truth apart from release truth. The source record answers one question: what value is controlled here right now? The release decision answers another: may this value appear in this customer document for this purpose? A proposal may need to hold back a connected number because its evidence or review is not ready.

Which seven numbers should never be re-entered manually?

Connect seven families of numbers 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
• system price or payment figures

Treat each as a structured record. Give it units, a source, a version, dependencies, a review state, and a release status.

1. Roof and site geometry

Many roof and site figures can feed design decisions. They include lengths, areas, slopes, and azimuths (the compass direction a roof faces). They also include heights, offsets, obstruction sizes, and coordinate links. A proposal coordinator should not read a size off a drawing and type it into a customer document as a new fact.

The controlled geometry record needs these items:

• the project and surface identity
• the value and its unit
• the method and the source
• the observation date
• the uncertainty or resolution, where it applies
• the coordinate or scale link
• the responsible reviewer

A modeled roof plane must stay different from a field measurement and from a size the customer stated.

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

2. Module quantity and DC nameplate capacity

Module count and DC capacity (the rated size of the panels) should come from the released layout and the selected equipment record. Retyping either one invites mismatches. They can appear in the plan, equipment list, and system summary. They can also appear in the production model, price basis, and proposal text.

Store the module model, the rating from the approved equipment source, the quantity, the layout version, the status, and how they are calculated. Any capacity you show needs a checked calculation with units. A layout change should regenerate the dependent capacity. Do not rely on a coordinator to remember the multiplication.

Do not let the proposal become the authority for module count. Say sales asks for a different count. Route it as a design change. When a qualified reviewer accepts the new layout, the proposal picks up that released state.

3. Shading and system-loss inputs

Many modeled losses can change an energy result a lot. Examples are shade, soiling (dirt on the panels), mismatch, wiring, availability, and degradation. The proposal should not hold a “loss percentage” that someone typed on their own, when no one knows its model, scope, or period.

Connect each input to the model and scenario where it is used. Keep a note of whether it is measured, modeled, defaulted, estimated, specific to the customer, or waiting for review. A label such as “system losses” is not enough. Different tools or versions include different parts.

The shading communication guide explains why you should not reveal an early input as a surprise later. A connection helps the technical record and the customer explanation point to the same assumption.

4. Modeled annual and periodic energy yield

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

The Department of Energy’s PV system design overview says a solar module is only one part of a complete photovoltaic system. Whatever approved model the company uses, the customer-facing value needs a set of details. These are the model, input set, scenario, run time, version, unit, period, reviewer, and limits.

Keep modeled output apart from measured past performance. A proposal for a system that is not built yet shows a model, not an observation. If the current model is not released, the proposal should leave out the value. Or it should use a clearly bounded scenario approved for that decision.

5. Customer consumption and planned-load inputs

Annual use, monthly use, interval data, demand, and planned load changes should connect to their utility or approved customer source. A number copied from one page of a bill can lose its service, meter, period, units, adjustments, and link to the right property.

Record these items:

• the source document or data export
• the customer and account scope
• the service identity
• the period covered
• the unit
• any missing intervals
• any changes made to the data
• the status
• the reviewer

A customer’s word about a future electric vehicle or heat pump is not a measured load. Store it as a scenario input that still needs evidence.

The Department of Energy’s homeowner solar guide says savings depend on how much electricity you consume and on the system size. They also depend on whether you buy or lease and on how much the system generates. Utility rates and what the utility pays for exported power matter too. The utility-bill reading guide covers the source questions that should go with the number.

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

Many inputs can change a financial scenario:

• utility rates and rate structures
• escalation assumptions (how much you expect a rate to rise each year)
• discount rates
• incentive inputs
• tax assumptions
• financing terms
• analysis periods

They also change with time and place, they are often specific to a customer, and they often need professional review.

Do not type a rate or incentive into the proposal from memory. Connect the approved assumption record. It should carry the source, the place, the effective date, and the eligibility limit. It should also carry the expiry, the units, the scenario, the owner, and the review. If a value is only an example, label it as an example. Keep it out of any conclusion that is specific to a customer.

No connected field makes advice automatic. That covers tax, finance, accounting, utility, and incentive advice. Qualified owners must decide what may be used and how it is disclosed. A connected value that is out of date is still out of date. That is why claim expiry and release review matter.

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

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

Every total you show needs a defined calculation or a value returned by the official source. Keep price parts and approvals in view. A discount request should create a controlled commercial change. It should not be a hidden edit to the proposal total. Financing outputs should come from the responsible approved source and get the qualified review they need.

The customer document must match the current supported commercial record. An approved price source does not automatically approve the words around it. That includes words about savings, affordability, and urgency. It also includes words about eligibility, financing, or performance. Each claim the customer sees needs its own evidence and its own release decision.

How should numbers move from source records into the proposal?

Map each proposal number to one official source. Keep its meaning and unit. Check the connection. State all dependencies. Require the right review. Then generate the proposal from a released project state. When an upstream value changes, mark every dependent output stale. Keep it 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 text, tables, charts, and diagrams. Include equipment lists, summaries, footnotes, CTA calculators, and attachments.
2. Name the semantic field. “Annual energy” needs a unit, period, scenario, model, and meaning. A cell address is not enough.
3. Assign the official source. Record its owner, id, access rule, update event, version, and expiry.
4. Map transformations. Document unit conversion, grouping, rounding, and calculation. Document formatting and model dependencies.
5. Validate by script where arithmetic exists. Check typed units and dimensional compatibility before computing.
6. Declare stale conditions. Map which outputs a change to layout, equipment, usage, tariff, price or finance affects. Set up automatic flags where the tool supports them. Otherwise assign a documented check before release.
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. A hash is a digital fingerprint of the file. Keep the source versions, proposal version, release event, and exact file.
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 you find conflicts after a revision. A lineage map solves the problem earlier. It shows which outputs to regenerate when a source changes.

How should manual-entry exceptions be handled?

Treat every manual entry downstream as a controlled exception. Record these items:

• the reason
• the evidence
• the old and new values
• the units and scope
• the editor and the reviewer
• the affected dependencies
• the expiry
• the person who will reconcile it

Block release when the exception changes a technical, financial, contract, or customer claim that nobody has reviewed. The exception closes only when the official source and the 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 cases means you should pretend the retyped value is connected.

Use an exception ladder:

• Prefer a source correction. Update the official 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 you cannot avoid typing, require a second-source or double-entry comparison that fits the risk. Keep the source and mark the field as imported.
• Use a proposal-only override only as an emergency exception. State why the source cannot be changed. Block unintended reuse, assign reconciliation, and set the override to expire.
• Withhold the number when evidence is inadequate. A blank, a bounded range, or a held proposal is safer than a precise value you cannot support.

Do not turn overrides into a permanent shadow spreadsheet. Review exception patterns by source, field, interface, team, and dependency. Overrides that keep coming back are a workflow bottleneck. See the workflow bottlenecks to remove before scaling lead volume. The goal is not to blame the coordinator who caught the gap. The goal is to remove a second, independent state that keeps coming back.

NASA’s technical-assessment guidance describes three steps. Turn status reports into trends. Understand variances from expected results. Take corrective action where needed. Do the same with a proposal field. Compare it with its source and record the variance and the fix. Do not only confirm 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 may mean kilowatt-hours per year. Another may be a currency amount, and another may be annual consumption. A check that two values are equal does not check what they mean.

The connection contract needs the field id, type, unit, scale, period, and scenario. It also needs the jurisdiction where it applies, allowed rounding, null behavior, and version. Check 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 name the source, owner, unit, transformation, dependencies, stale events, reviewer, customer display, and release state. Add an exception section that keeps any manual override and how it was reconciled. Review the record whenever a template, integration, model, product, or source changes.

Copy-ready solar proposal number-control record

Illustrative example, not a customer case or measured result. A layout revision changes the approved module quantity. The capacity and yield outputs need to be checked again. But a legacy pricing sheet does not get that event.

The proposal coordinator does not type the new count into the PDF and leave the other figures alone. The team holds the release. It updates the official layout and recomputes the checked capacity. It reruns the approved yield model. It sends the commercial record for any scope and price review that is needed.

Say the legacy price must be typed in by hand. Then the record names its source, unit, scope, and version. It also names the editor, the comparison check, the reviewer, and the owner who will reconcile it. The customer gets no promise on production, savings, price, or timeline until the responsible outputs are released.

Worked example with hypothetical numbers (not a customer case or a yield estimate): The old design has 24 modules of 400 W, so 24 × 400 W = 9,600 W, or 9.6 kW DC. The revised design has 20 modules, so 20 × 400 W = 8,000 W, or 8.0 kW DC. Suppose the model gives 1,300 kWh per kW DC per year for this site. The old design is 9.6 × 1,300 = 12,480 kWh a year. The revised design is 8.0 × 1,300 = 10,400 kWh a year. Now someone retypes the old 12,480 kWh into the savings page. That overstates production by 12,480 − 10,400 = 2,080 kWh. This is 2,080 ÷ 10,400 = 20% of the correct figure. Every savings number built on it inherits that error. Linking the savings page to the yield result removes the retype.

Evaluate the solar proposal workflow with a cleaned-up sample project and one changed module quantity. Ask the demonstrator to trace its effect on capacity, modeled yield, materials, price and the customer document. Confirm which source identifiers, versions, dependencies and exception records your setup keeps. Also confirm which checks your team must do separately.

SurgePV supports roof modeling, array layout, shading, energy-yield and financial modeling, electrical workflow support, bill-of-materials output and proposal generation in one project. Results depend on source data, assumptions, equipment models, setup and review.

Before releasing a proposal, choose one material number. Trace its source, version, change dependencies and release decision. If that trace fails, fix the missing connection before you treat the document as current.

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 stay believable while it points to an older layout, a different utility period, the wrong equipment set, or a replaced price. The fix is not blind automation. It is connected data plus checks, approval, exception handling, and release evidence.

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

No. Correct the official source through an approved change. Keep the earlier value, state the reason and evidence, get the review you need, and regenerate the outputs that depend on it. Say an emergency fix must be made downstream. Then label it an exception, block silent reuse, reconcile it upstream, and require the receiving owner to accept it before release.

Which solar proposal number should be connected first?

Start with the number whose error would do the most harm to the customer and the workflow, based on the company’s own evidence. Often that is project identity, system capacity, or modeled production. It may also be consumption, price, or a financial assumption. Map the dependencies before you set priorities. Do not use one fixed order without weighing technical, financial, contract, and legal risk in your region.

Can proposal software guarantee that every number is correct?

No. Connected software cuts the number of places a value is retyped and keeps each number tied to its source. Correctness still depends on source data, units, and assumptions. It also depends on equipment models, configuration, integrations, review and qualified decisions. Your team checks utility records, tariffs and incentives, and signs off engineering and financial terms.

How should a proposal display an important modeled number?

Show the value with its unit, meaning, model or source, period, scenario, version, and key assumptions, at the level a reviewer needs. Keep five kinds of value apart: measured, customer-stated, source-recorded, calculated, and modeled. If the current evidence cannot support the number, leave it out. Or show a clearly bounded scenario, or hold the proposal for review.