8 Consumption Errors That Distort Solar Advice

A consumption file can look reassuringly complete while carrying the wrong story about a facility. Rows arrive every fifteen minutes, totals appear plausible, and the chart has the familiar morning rise. Yet one shifted time zone or one missing production line can push a solar recommendation toward the wrong size, operating case, or savings narrative.

This guide is for commercial solar sales, design, and analysis teams that receive utility exports before a proposal. It identifies eight errors worth finding before anyone treats the load profile as decision evidence. The practical standard is simple: a profile must be traceable to meters and bills, representative of the proposed boundary, and honest about what was measured versus reconstructed.

The U.S. Department of Energy’s commercial reference building resources illustrate why building loads differ by use and climate. Reference profiles are useful for comparison, but the customer’s own data remains the basis for a project recommendation. A polished generic curve cannot substitute for a verified facility record.

Treat the load profile as an evidence record

A load profile is a time series of electrical use. Its interval may be five minutes, fifteen minutes, thirty minutes, or an hour. Every row needs a timestamp, value, unit, meter identity, and enough context to explain how the utility produced it. Without those fields, analysts can still draw a chart, but they cannot reliably explain what the chart represents.

Start with provenance. Record who supplied the file, when it was exported, which account and meters it covers, the utility’s stated unit, and whether timestamps mark the beginning or end of each interval. Preserve the original file. Transformations belong in a separate working copy with a change log.

Then reconcile. Compare each meter’s interval sum with bills covering the same dates. Do not force equality without investigating billing adjustments, read dates, losses, netting, or demand-only channels. The purpose is to understand differences, not to make the spreadsheet turn green.

The profile also needs a decision boundary. A tenant meter may represent only part of a shopping center. A campus account may include buildings outside the proposed interconnection. A behind-the-meter generator can reduce utility-recorded imports without reducing the site’s actual electricity demand. State what is inside the recommendation and what remains outside it.

Error 1: missing intervals are mistaken for low consumption

A blank interval is not a zero. Zero means the meter recorded no energy for that period. A blank can mean an export failure, communications problem, file truncation, meter replacement, or a rule that suppressed a value. Converting blanks to zero quietly lowers annual consumption and can reshape the apparent daytime load.

Profile the file before modeling. Count expected intervals by local calendar day, then compare them with received rows. Look for long gaps, isolated holes, duplicate timestamps, and days whose interval count changes. Daylight-saving transitions deserve special attention because local-time files may contain a repeated or absent clock hour.

The correction depends on cause. A short communications gap on an ordinary weekday may support imputation from comparable days. A gap during a plant shutdown, holiday, heat event, or production launch does not. Label every substituted value and retain the original observation status beside it.

Test the recommendation twice when the gap matters. One scenario can use the documented replacement method. A second can use a conservative boundary or exclude the affected decision. If the preferred array or economic case changes, the missing data is a project risk, not a clerical footnote.

Do not let interpolation produce false precision. A smooth line can look more credible than a visibly broken one, which is exactly why reviewers need an imputation flag. The customer should be able to distinguish readings from estimates when discussing system size or expected grid interaction.

Error 2: timestamps are read in the wrong time basis

Solar production and electricity use meet in time. A profile shifted by one hour can move the apparent peak away from the modeled solar window. The annual kilowatt-hour total stays the same, so an annual reconciliation will not expose the error.

Confirm the utility’s convention. The export may use local standard time, local civil time with daylight saving, coordinated universal time, or an interval-ending label. Some files include a time-zone field; others describe it only in portal documentation. Record the source rather than guessing from the customer’s address.

Plot several known operating days. Ask the facility contact when doors open, major equipment starts, lunch occurs, and shifts end. A midnight production peak at an office is a clue. It is not proof of a time-zone error because refrigeration, charging, process loads, and scheduled equipment can operate overnight.

Normalize timestamps in a reversible step. Keep the supplied timestamp, parsed timestamp, time zone, and adjustment in separate columns. That makes a reviewer able to reproduce the coincidence analysis and prevents a future export from being shifted twice.

Time alignment matters beyond energy totals. Time-of-use periods, demand windows, export rules, and storage dispatch can all depend on the clock. A recommendation using those elements should cite the current tariff and confirm how the utility assigns intervals. The EIA overview of electricity prices explains that rates reflect several cost factors, but project billing still depends on the customer’s actual utility schedule.

Error 3: energy and demand channels are confused

Kilowatts and kilowatt-hours answer different questions. A kilowatt channel describes power or demand at an instant or over a defined averaging interval. A kilowatt-hour channel describes energy accumulated during an interval. Treating one as the other can multiply or divide consumption by the interval length and still leave a curve that looks believable.

Read the channel definition. Do not infer units from the column heading alone. Utility exports may label fields with abbreviations, meter register codes, multipliers, or engineering units stored elsewhere. Demand may be an interval average, rolling value, or maximum registered for a billing period.

Keep transformations explicit. If a valid average-power channel is converted to interval energy, document the interval duration and calculate by script. If the interval duration varies because of missing rows or clock changes, do not apply one blanket conversion until timestamps are normalized.

For a documented interval-average power channel, interval energy (kWh) = average power (kW) × elapsed interval duration (hours). The EIA explanation of electricity units distinguishes power from energy used over time. This conversion does not apply directly to an instantaneous sample, a recorded maximum or a cumulative energy register. A missing row does not prove that the previous average applies across the gap.

Demand peaks also require restraint. A fifteen-minute average is not interchangeable with an instantaneous spike, and a billing demand may include ratchets or special definitions. The profile can support exploration, while the tariff and bills control the actual billing interpretation.

A reviewer should see a compact data dictionary with original field, unit, interval meaning, multiplier, and transformed field. This small document prevents the same ambiguity from spreading into energy models, financial models, and customer proposals.

Keep the reviewed consumption scenario beside the generation and financial modeling workflow so a corrected meter interpretation can be traced into the customer case.

Error 4: meter boundaries are mixed or duplicated

Commercial accounts often arrive as a folder rather than one clean series. There may be main services, submetered tenants, solar production meters, common-area loads, and old meter identifiers that changed during the period. Adding every column can double count a submeter already included behind a main meter.

Create a meter map before aggregation. For each identifier, record physical location, account, service, direction of energy flow, relationship to other meters, date range, and proposed project boundary. Ask the customer or utility to resolve ambiguous relationships rather than choosing the interpretation that supports a larger system.

Net meters need special care. Utility imports after existing onsite generation are not necessarily total facility consumption. A separate production channel may allow reconstruction, but only if timestamps, units, and meter direction are understood. Do not call a reconstructed series measured consumption without stating the calculation and sources.

For a simple site with PV and no storage or other generation, aligned energy channels at a consistent AC boundary can support the balance: facility load = grid import + PV generation − grid export. Adding PV generation to imports alone overstates load when some generation was exported. Storage charging, discharging, losses and other sources require their own boundary accounting; do not reuse the simple balance without those terms. This is a reconstructed load, not a direct load measurement.

Changes during the year can break continuity. A meter exchange may reset an identifier, alter interval length, or split one service into two. A building acquisition or tenant move can add load that belongs to a different commercial decision. Mark these events on the profile and decide whether they form one representative period.

Aggregate only after each component reconciles. This sequence catches duplicates earlier and leaves a readable audit trail. It also supports later changes: if the customer removes one building from scope, the analyst can rebuild the profile without starting from an opaque combined column.

Error 5: estimated values lose their labels

Utilities and analysts may estimate readings for legitimate reasons. The error begins when estimated values become visually identical to meter observations. A later reviewer sees one continuous line and assumes one evidence class.

Retain the quality flag from the source file. If the utility labels reads as actual, estimated, corrected, or substituted, preserve that status. When your team creates an estimate, add method, author, date, and reason. Never overwrite the raw value.

Choose a method that fits the gap and use case. Comparable-day substitution may fit a stable office better than a manufacturing line with irregular batches. Weather-based estimation needs suitable weather evidence and a documented relationship. A simple average can erase the very peak that drives the decision.

Separate materiality from row count. Ten missing overnight readings might have little effect on a daytime solar discussion. One missing weekday during a demand event could matter far more. Evaluate how the uncertain period affects annual energy, solar coincidence, peak demand, and the recommendation itself.

Show uncertainty at the proposal boundary. The customer does not need every cleaning rule, but should see that a portion of the profile was estimated and what happens next. A sentence such as “two weekdays were reconstructed from comparable operating days and will be replaced if the utility supplies corrected data” is more useful than a generic accuracy disclaimer.

For the broader intake process, use a versioned record such as the solar project intake process instead of passing a cleaned CSV between inboxes without context.

Error 6: billing totals are matched to the wrong dates

Calendar months and billing periods need not be identical. A bill can begin or end midmonth, include an estimated read, carry an adjustment, or cover a meter-change event. Comparing January interval data with a bill labeled January can create a difference that belongs to date boundaries rather than bad data.

Use service dates from the bill. Sum intervals between the defined start and end, accounting for the utility’s interval-ending convention. If one timestamp sits exactly on the boundary, document which period receives it. A consistent off-by-one-interval rule is still wrong.

Reconcile energy charges separately from non-energy line items. Taxes, fixed fees, minimum bills, riders, demand charges, and credits do not belong in a kilowatt-hour tie-out. Likewise, a billed-energy value may reflect netting or a multiplier that the raw export handles differently.

Build a reconciliation table by meter and bill period. Include interval sum, billed energy, absolute difference, stated reason, and status. Avoid declaring a universal tolerance without the utility’s data specification and project needs. A small unexplained difference may still expose a systematic unit or boundary error.

When a correction arrives, rerun dependent scenarios and retain the earlier version. The solar design review checklist is a useful home for confirming that updated evidence reached layout, production, economics, and proposal outputs.

Error 7: one season is presented as a normal year

A three-month export can be perfectly clean and still poorly represent annual operations. Weather-sensitive cooling, heating, irrigation, tourism, school calendars, agricultural work, and holiday production can create seasonal patterns. Multiplying one quarter by four hides those mechanisms.

Request the longest relevant history available and state what the received period includes. A full calendar year can show seasonality, but it may still be atypical because of shutdowns, vacancies, renovations, or unusual operations. More rows do not remove the need for context.

Compare interval totals with multiple bills where possible. Ask the customer to identify known events and planned changes. Use public reference profiles as a reasonableness check, not a replacement. NLR’s End-Use Load Profiles work and ComStock platform provide modeled building-stock resources, while a specific recommendation still depends on the facility’s evidence.

If only a short period exists, narrow the claim. Present a preliminary scenario based on the observed window, disclose the missing seasons, and show which conclusions are stable or unstable. Do not manufacture an annual load by selecting whichever benchmark makes the economics look attractive.

Seasonality also affects timing. Annual energy might be similar across two facilities, yet one consumes heavily during sunny afternoons while the other peaks at night or in winter. The recommendation should preserve that distinction rather than collapsing both into one annual number.

Error 8: future operations are treated as settled facts

Historical data describes the past boundary. A solar project may serve a future factory line, electric fleet, heat-pump conversion, tenant mix, or reduced production schedule. Ignoring a credible change can understate or overstate future load. Treating a hopeful plan as certain creates the opposite problem.

Record operational changes as scenarios with owners and dates. Distinguish committed changes from approved budgets, active procurement, early plans, and ideas. Ask for equipment schedules, nameplate information, expected duty cycles, commissioning dates, and the internal decision that supports the assumption.

Do not bury future load inside the historical series. Keep a measured baseline and add scenario layers. This allows the customer to see how much of the recommendation rests on meter evidence and how much rests on plans that may move.

Test timing as well as annual consumption. An electric fleet charging overnight may add substantial energy with limited direct solar coincidence unless charging controls or storage change the pattern. A daytime process line may behave differently. These are modeling questions, not reasons to promise a result before operations are defined.

Give uncertain growth an exit path. The project can preserve expansion space, phase capacity, or set a review trigger without pretending that one forecast is final. The recommendation should say what evidence would cause it to change.

A review sequence that catches profile errors early

Run the checks before detailed layout and economics. Late discovery can require rework when the affected profile has already reached energy models, proposal charts and sales explanations.

1. Freeze the original exports and bills with received dates.
2. Map accounts, meters, channels, units, and service boundaries.
3. Parse timestamps without overwriting the supplied values.
4. Count expected rows and classify gaps, duplicates, and estimates.
5. Reconcile each meter to matching bill service periods.
6. Mark operational events and judge representativeness.
7. Build measured-baseline and future-change scenarios separately.
8. Compare scenario effects on layout, production, demand, and economics.
9. Send material discrepancies to an owner with a due date.
10. Release only the scenario whose status the proposal describes accurately.

The handoff should carry the profile version, reconciliation record, open issues, and approved scenario. A screenshot of the finished curve is insufficient. The solar sales and design handoff guide explains how to keep assumptions from being lost between commercial and technical roles.

Use a decision log for corrections. Record the old value, new value, evidence, affected outputs, reviewer, and approval date. This does not make data perfect. It makes the recommendation explainable.

What consumption data should a solar team collect before modeling?

A solar team should collect interval exports, matching bills, account and meter identifiers, channel definitions, units, timestamp conventions, quality flags, service dates, and known operating events before modeling consumption. The intake should also name the proposed project boundary, planned facility changes, data owner, received date, unresolved gaps, and the person authorized to explain each meter’s physical relationship to the site.

Ask for native exports when possible. A screenshot can confirm that a portal displays a value, but it usually drops row-level timestamps, flags, and channel metadata. A manually rearranged spreadsheet may be useful, yet it should arrive beside the original so the analyst can see which transformations occurred before intake.

Use this copy-ready intake record:

Commercial consumption data intake record

Customer, facility, and project identifier: [controlled identifiers]

Utility, account, and tariff references: [current references]

Meter identifiers and physical locations: [one line per meter]

Meter relationship: [main, submeter, generation, net, or unresolved]

Export source, requested period, and received period: [details]

Timestamp convention and time zone: [utility definition]

Channels, units, multipliers, and interval meaning: [data dictionary]

Source quality flags: [actual, estimated, corrected, or other defined status]

Matching bills received: [service dates by meter]

Known gaps, duplicates, or meter changes: [events]

Facility operating events: [shutdowns, vacancies, schedule changes, or launches]

Planned load changes: [status, owner, timing, and supporting record]

Proposed project boundary: [included and excluded loads]

Open questions and owners: [release blockers]

Do not turn “customer did not know” into a guessed field. Mark the item unresolved, explain why it matters, and name the evidence that would answer it. The project may still support a preliminary concept, but its recommendation language must stay within the verified boundary.

The intake should distinguish a missing record from a non-applicable record. A facility with no onsite generation is different from a facility whose generation meter was never requested. Likewise, no planned operating change means the customer affirmatively confirmed the current plan, while a blank future-load field means nobody asked.

Add a simple identity sketch for multi-meter sites. It can be a diagram or table showing which services include which buildings, submeters, onsite sources, tenants, and proposed interconnection points. The sketch is more useful than a single combined total because it lets a reviewer challenge one relationship without dismantling the entire profile.

Finish intake with a handoff conversation. The analyst should repeat the assumed boundary and major operating events to the facility contact, then retain any correction as customer-provided evidence pending verification. That small loop catches misunderstandings before a clean chart makes them harder to notice.

How should interval consumption data be reconciled to utility bills?

Consumption data should be reconciled meter by meter against bills covering the same service dates, while preserving the original timestamps, units, multipliers, and quality flags. The reviewer should explain differences instead of forcing agreement, then test whether unresolved gaps, boundary questions, or transformations can change system sizing, solar coincidence, demand treatment, export assumptions, storage operation, or the customer-facing recommendation directly.

Build the reconciliation from the raw boundary outward. First identify which interval rows belong inside each bill service period under the utility’s timestamp convention. Next compare the energy channel to the billed energy field that actually corresponds to it. Keep demand, fixed charges, taxes, credits, and other monetary lines outside the energy tie-out unless a qualified tariff review gives them a defined role.

Use a working table that exposes the investigation:

Reconciliation is not a hunt for identical numbers. Bills and interval exports can reflect different boundaries, adjustments, netting, read conventions, or processing. The reviewer needs a documented explanation that is adequate for the decision. If no explanation is available, preserve the difference as an open risk and test its consequence.

Illustrative workflow example, not a customer result: An analyst finds that the interval curve and billed energy do not reconcile for one service period. Instead of scaling the curve until the totals match, the analyst freezes the original file, checks the meter identity and bill dates, and asks the facility contact about a documented meter change. The project owner keeps the recommendation conditional until the boundary and transformation rule receive review.

When a correction is justified, apply it in a reproducible working copy. Record the original field, corrected field, method, reason, source, reviewer, and date. Recalculate by script where arithmetic is required, retain the calculation record, and rerun every dependent scenario whose input changed.

Then compare decision outcomes rather than only data totals. A discrepancy may have little effect on one preliminary annual-energy discussion and a material effect on a demand or storage question. Avoid declaring the file “good” or “bad” globally. State which uses the reviewed profile supports and which uses remain blocked.

When should a solar recommendation pause for consumption-data review?

A solar recommendation should pause when the team cannot identify the meter boundary, confirm units or timestamps, reconcile material differences, distinguish measured from estimated values, or explain whether the observed period represents expected operations. It should also pause when a future-load assumption controls the decision but lacks an owner, record, timing basis, or approved scenario that the customer can review.

A pause keeps the current analysis visible while preventing the proposal from converting an open data question into a confident design or savings statement. Name the exact decision that is blocked. “Data quality issue” is too vague for an owner to resolve and too broad for a customer to understand.

Use these release-stop conditions:

• A meter, account, service, direction of flow, or relationship to another meter remains unknown.
• The team inferred a channel unit, multiplier, interval duration, timestamp convention, or time zone without supporting documentation.
• Missing, repeated, or estimated intervals overlap an event that could affect the recommendation, and no defensible treatment has been reviewed.
• The interval and bill records show an unexplained difference that could change the selected scenario.
• The received period excludes a relevant season or operating state, but the proposal presents it as representative.
• Historical load includes an operation outside the future project boundary, or omits a committed future load.
• A future-load scenario depends on an idea or verbal expectation that has no accountable owner or supporting plan.
• A transformed or imputed series is displayed as measured data.
• The corrected profile has not reached the energy, financial, storage, tariff, or proposal work it affects.

Create a data-exception record for every stop:

Consumption data exception

Exception: [specific missing, conflicting, or uncertain item]

Evidence observed: [files and dates]

Decision affected: [sizing, coincidence, demand, export, storage, or other]

Current allowed use: [none, preliminary concept, or named conditional analysis]

Resolution evidence needed: [specific record or review]

Owner and next trigger: [person and event]

Dependent outputs to rerun: [controlled list]

The exception record prevents two bad outcomes. It stops a reviewer from rejecting an entire useful dataset because one use is blocked, and it stops a salesperson from treating partial usability as full validation. The allowed-use field carries the distinction into the proposal workflow.

Once the evidence arrives, resolve the item through the change log and issue a new profile revision. Do not simply remove the warning from an old chart. Compare the old and new recommendations, identify what moved, and explain the change to the customer if they saw the earlier scenario.

Qualified technical, tariff, utility, engineering, financial, and contract review still governs the relevant decisions. The exception workflow organizes evidence and handoffs. It does not turn a solar software output or internal checklist into professional approval.

Read the recommendation through four lenses

First, ask whether the profile represents the right physical and contractual boundary. A clean series for the wrong meter is still wrong. Second, ask whether time, units, and quality flags survived transformation. Third, ask whether the observed period represents expected operations. Fourth, ask whether the customer understands remaining uncertainty.

Review layout and energy together. PVWatts and the System Advisor Model are calculation tools with defined inputs. Neither can repair an unverified consumption profile. The load model and production model must each preserve their own assumptions before anyone compares them.

Avoid a single “data quality score” unless its dimensions and decision rule are visible. Missing rows, wrong meters, and future-use uncertainty are different defects. A composite score can hide a severe boundary error behind several clean formatting checks.

The strongest recommendation may be a conditional one. “Proceed with this concept if meter B belongs inside the interconnection boundary” tells the team exactly what to resolve. A confident number based on an unresolved meter map does not.

Results depend on source data, assumptions, equipment models, configuration, and review. Outputs support design and documentation workflows but do not replace approval by the responsible engineer, authority, lender, insurer, or utility.

Frequently Asked Questions

How much consumption data should a solar team request?

Request the longest relevant period the customer can provide, including interval exports and matching bills. A full year is useful for seasonality, but duration alone does not prove quality. Check meter coverage, timestamp basis, gaps, operating changes, and whether the period represents the facility’s expected future use.

Can monthly utility bills replace interval data?

Monthly bills can support an annual energy comparison and a preliminary concept, but they hide time-of-use and demand patterns. For a decision affected by coincidence between load and solar production, demand charges, storage, or export limits, interval data usually provides the needed timing detail, subject to utility data availability and review.

Should missing intervals be filled automatically?

Automatic filling is acceptable only as an explicit modeling choice with a suitable method, visible flags, and a sensitivity check. Never let imputed values look measured. First determine why data is missing, whether the gap covers a special event, and whether the recommendation changes under a conservative replacement or exclusion.

Why can two correct meter files still create a wrong profile?

Two valid files can represent different premises, account boundaries, time zones, units, or date ranges. Combining them without an identity map can double count load or omit a service. Reconcile each meter separately to its bill, then document the rule used to aggregate meters into the proposed project boundary.

When should a solar recommendation be rerun?

Rerun it when corrected data changes annual use, timing, demand peaks, meter coverage, operating assumptions, or the proposed system boundary enough to affect the decision. Also rerun after material customer plans become firmer. Keep prior scenarios so reviewers can see which input change moved the recommendation.