Quick Answer
Review a consumption profile by validating the meter, interval, units, dates, time zone, missing data, and site changes before comparing it with solar output on the same timeline. Examine imports, exports, peaks, operating-day patterns, and scenario assumptions separately. Annual consumption and annual production alone cannot show when energy overlaps.
Annual consumption can make a solar proposal look balanced while the interval data tells a different story. A warehouse may use most of its energy after sunset. A school may empty during part of the strongest solar season. A factory can show one annual total that combines production days, shutdowns, and a new line installed midway through the year.
Reviewing consumption against a proposed system means placing site use and modeled PV output on the same clock, then inspecting where they overlap and where they do not. It also means preserving what the data cannot answer. A polished chart should not turn an estimated load shape into measured behavior.
This guide is for commercial solar analysts, designers, sales engineers, and operations teams. It is a desk-research process, not a financial, tariff, engineering, or utility determination. Use current meter records, tariff documents, site information, model documentation, and qualified review for the actual project.
Start with the customer decision
A load review should support a specific question. One customer may want to understand daytime energy overlap. Another may care about demand peaks, export, a future EV fleet, an operating-hours change, or battery scenarios. The same dataset can be useful for one question and inadequate for another.
Write the decision before opening the spreadsheet:
Compare the proposed PV scenario with the facility’s recent interval consumption to show modeled on-site use and export by month, while keeping demand-charge and future-load questions separate.
That illustrative statement defines a boundary. It prevents the analyst from presenting an annual production match as a complete bill analysis. It also tells the team which additional sources are needed, including tariff schedules and operating plans.
The U.S. Energy Information Administration explains broad patterns in electricity use and publishes electricity data at national and sector levels. Those sources help with context. They cannot replace the site’s meter data or explain a particular facility’s schedule.
Prove that the consumption file belongs to the site
Before inspecting peaks, identify the data. Commercial customers may have multiple accounts, meters, buildings, service points, tenants, and utility files. A twelve-month CSV is not useful if nobody can say which load it represents.
Create a provenance header with:
- customer, facility, address, account, and meter identifiers as permitted;
- utility or data provider;
- start and end timestamp;
- interval length and unit;
- time zone and daylight-saving treatment;
- import, export, net, or channel definition;
- date received and source person or system;
- known meter replacements, resets, or account changes;
- privacy and access controls for customer data.
Compare interval totals with bills or another independent record where the units and periods allow. Do not force agreement when billing periods and calendar months differ. Record the alignment method, excluded partial intervals, and any unexplained variance for follow-up.
ENERGY STAR’s building benchmarking resources describe tracking and comparing building energy performance. Benchmarking and PV load matching are different tasks, but both depend on correct property and meter information. A facility record should be identifiable before its patterns are interpreted.
What should a consumption-data identity record contain?
A consumption-data identity record should contain the customer-authorized site, account and meter boundaries, provider, channel definition, units, interval convention, time zone, coverage dates, receipt source, privacy controls, meter changes, transformations, quality findings, and intended decision. It should identify bills or other independent records used for reconciliation, so a clean curve cannot conceal the wrong facility, netting boundary, or partial period.
Keep identity separate from analysis. The same raw file can support several scenarios, but its meter, channel, and time meaning should not change between them. Store transformations as reproducible steps rather than exporting a cleaned spreadsheet with no path back to the received data.
Use this identity table:
| Identity field | Record | Review question |
|---|---|---|
| Customer authorization | Approved source and permitted users | May the team use and share this data for the decision? |
| Site boundary | Facility, building, service, account, and meter IDs | Which physical and billing load does the file represent? |
| Channel definition | Import, export, net, gross, demand, or other measurement | What does each signed value mean? |
| Time basis | Start/end stamp, interval length, zone, daylight-saving treatment | Which real period does each row cover? |
| Units | Energy, power, multiplier, and conversion source | Can the series be aggregated correctly? |
| Coverage | First/last interval, missing periods, partial days | Is the observation window complete enough for its use? |
| Meter history | Replacements, resets, multiplier changes, account changes | Where can the series change meaning? |
| Transformations | Import, deduplication, aggregation, correction, imputation | Can another analyst reproduce the cleaned series? |
| Reconciliation | Bills or another accepted record, aligned periods, unresolved variance | Does an independent source support the boundary? |
| Decision | Baseline, overlap, demand, tariff, forecast, or another named use | Is this identity sufficient for the question? |
Use this copy-ready provenance header:
Customer, facility, and service boundary:
Accounts, meters, and channels included:
Provider and receipt source:
Coverage, interval, units, and time convention:
Import, export, or net definition:
Meter and account changes:
Transformations and quality flags:
Independent reconciliation:
Privacy and access boundary:
Decision supported and prohibited use:
Use only the personal and account information needed for the project. Access, retention, sharing, and disposal should follow customer authorization, current applicable requirements, contracts, and company policy. A reader-facing report can use a project identifier while the protected source record retains the meter details.
If identity remains unresolved, stop interpretation. A plausible industrial load shape does not prove that the file belongs to the intended facility. Ask the provider or customer for a source record rather than matching the curve to expectations.
Normalize the clock before comparing curves
Consumption and production data must refer to the same intervals. A timestamp can mark the beginning or end of an interval. One file may use local standard time, another local clock time with daylight saving, and a third Coordinated Universal Time. An unnoticed offset can make solar appear to serve evening load or miss midday operations.
Document and test:
| Time property | Check | Failure symptom |
|---|---|---|
| Time zone | Explicit zone for both datasets | Peaks shifted by whole hours |
| Interval convention | Beginning or ending timestamp | Curves displaced by one interval |
| Daylight saving | Duplicate and missing clock hours handled | One-hour steps at seasonal transitions |
| Interval duration | Same resolution or valid aggregation | Unequal energy totals |
| Leap day and partial days | Included consistently | Annual and monthly totals disagree |
Aggregate fine data to a coarser common interval when necessary, preserving energy units. Do not create finer measured-looking data by dividing a monthly total across hours. Synthetic profiles can be used as clearly labeled scenarios when there is a defensible method, but they are not observations from the meter.
Use a small spot check. Pick a known operating day, a closure day, and a day around a clock change if applicable. Compare the raw file, transformed data, and chart. A line that looks smooth can hide a timestamp error across the whole period.
Find gaps, duplicates, and impossible values
Plotting should come after data-quality checks. Count expected intervals by day and compare them with received records. Flag gaps, duplicates, negative values, flat lines, repeated blocks, meter resets, and extreme values for investigation. Whether a negative value is valid depends on whether the channel represents net flow or another signed measurement.
Do not automatically replace every anomaly. A zero may reflect a real shutdown. A peak may reflect equipment starting. A repeated day may be a data-system duplication. Contact the facility or data provider when the distinction changes the decision.
Use four disposition states:
- Accepted observation: evidence supports the value as recorded.
- Corrected source defect: a documented conversion or duplication error was repaired.
- Imputed value: an estimate filled a gap through a declared method.
- Excluded period: the interval was unsuitable for the analysis and remains visible in the exclusions.
If imputation is material, run the analysis with alternative reasonable treatments. The spread shows sensitivity to the missing data. Do not hide imputed intervals in the same series color and call the result measured.
How should missing or conflicting intervals be handled?
Handle missing or conflicting intervals by preserving the raw data, locating each affected period, checking meter and operating context, requesting a corrected source, and assigning accepted, corrected, imputed, or excluded status. Use estimation only through a reproducible method with visible lineage and sensitivity. Never spread monthly totals into observed-looking intervals or erase anomalies because they disrupt the expected load shape.
Use this sequence:
- Preserve the received file and calculate a reproducible source hash under the project workflow.
- Generate the expected timestamp index from the documented interval and clock convention.
- Identify missing, duplicate, overlapping, partial, signed, flat, or extreme records.
- Check meter events, account changes, holidays, shutdowns, outages, and operating notes.
- Request replacement data or provider clarification where the distinction affects the decision.
- Assign a disposition and retain the original value or absence beside the cleaned series.
- Route imputation method and materiality through the responsible analytical review.
- Compare reasonable treatments when uncertainty can change the conclusion.
- Mark every chart and table that contains imputed or excluded periods.
- Reopen dependent overlap, tariff, demand, storage, and proposal outputs after correction.
Illustrative workflow example, not a customer dataset or quantified result: A facility file contains a repeated block of intervals during a period the operations record describes as a shutdown. The values look plausible and could be mistaken for continued production. The analyst does not delete the block or accept it solely from visual judgment.
The team checks provider exports, meter history, bills where periods align, and the facility’s operating record. If the provider confirms duplication, the correction remains tied to that evidence. If the source cannot be resolved, the affected period stays flagged or excluded according to the approved method, and the analysis shows how the uncertainty limits its use.
Use a quality ticket:
Meter, channel, and period:
Observed data issue:
Source records checked:
Operating context:
Provider or customer response:
Disposition and method:
Measured, corrected, imputed, or excluded state:
Analyses and customer outputs affected:
Reviewer and reopen trigger:
Do not judge anomaly severity by visual size alone. A short gap can coincide with the facility peak or a tariff window, while a longer closure can be easy to identify and exclude. Severity follows the decision that the missing data can alter.
Decide whether the period represents future operations
A complete dataset can still be unrepresentative. Ask what changed during and after the observation period: occupancy, shifts, production, weather-sensitive loads, efficiency projects, HVAC, refrigeration, electrification, EV charging, tenant mix, construction, outages, and unusual closures.
Separate baseline from forecast. The baseline is an observed and cleaned historic series. The forecast is a scenario that applies documented changes. Keep both. If a facility plans a new production line, obtain the expected schedule and equipment information from the customer or responsible engineer rather than adding a round percentage to every interval.
EIA describes the U.S. electricity system and its parts in Electricity in the United States. National context does not determine a plant’s future load. The project forecast must come from site-specific plans and clearly stated assumptions.
Create scenarios only when they answer a decision:
- observed recent operations;
- normalized operations excluding a documented abnormal period;
- customer-supplied planned load change;
- alternative schedule or electrification case;
- downside or upside case for a material uncertain input.
Do not average them into one “expected” profile unless the customer has accepted a method and the weighting is supported.
Align modeled production with the same interval basis
The production series must describe the same PV configuration shown in the proposal. Record site, weather dataset, array geometry, equipment models, shading treatment, loss assumptions, simulation version, interval convention, and date. If the layout changes after simulation, regenerate or clearly restrict the analysis.
The Department of Energy’s overview of solar plus storage integration explains that storage can store energy for later use and support several grid and customer functions. A battery dispatch model adds another layer of assumptions. Do not treat simple PV-load overlap as proof of battery performance or economics.
Check production data in three ways:
- reconcile interval energy with the model’s reported monthly and annual totals;
- inspect daily shapes for impossible night production or timestamp offsets;
- verify that the configuration identifiers match the layout, equipment schedule, and proposal.
Keep modeled and measured words precise. A preconstruction PV series is modeled production. Historic facility consumption may be measured at the meter, subject to the data-quality findings. Their difference is a modeled comparison, not a measured future outcome.
Connect consumption assumptions to solar energy scenarios
Explore how SurgePV supports array layout, shading analysis, energy-yield modeling, financial modeling, and proposal generation from visible project inputs.
Explore energy and financial modelingCalculate overlap without losing the original series
For each aligned interval, the basic comparison separates site consumption, PV production, modeled on-site solar use, modeled export, and remaining grid import. Use a validated calculation with units. Preserve the input series and formula so the result can be reproduced when a scenario changes.
Do not do the arithmetic mentally for published results. The conceptual relationships are:
- on-site solar use is limited by both site consumption and PV production in the interval;
- modeled export is the portion of PV production above concurrent site consumption, subject to the system and interconnection model;
- remaining import is site consumption not served by concurrent modeled PV or modeled storage dispatch;
- self-consumption and solar fraction use different denominators and should not be swapped.
The model must also represent curtailment, export limits, storage, and other controls where those apply. A simple minimum calculation may be an early screen, not a final operational simulation.
Report energy quantities and ratios separately. A high self-consumption ratio can coexist with a small contribution to total site use if the PV system is small. A high solar fraction can produce substantial export if production and load timing diverge. The chart and table should make both relationships visible.
Read patterns before reading averages
Monthly totals are a useful orientation, but operational decisions live in distributions and exceptions. Build several views from the same accepted data:
| View | What it can reveal | What it cannot prove alone |
|---|---|---|
| Average weekday by month | Repeated operating pattern and solar timing | Variability or individual peak events |
| Heat map by day and hour | Closures, shifts, seasonal changes, anomalies | Tariff cost without rate logic |
| Duration curve | Distribution of load or net load levels | Chronological sequence |
| Representative days | Understandable operating examples | Whole-period totals unless weighted correctly |
| Monthly energy balance | Seasonal import, on-site use, and export | Short demand peaks |
Start with the ordinary week, then inspect the days that do not fit. A weekend production shift, holiday closure, maintenance outage, or heat event may explain a pattern that an average erases. Ask the facility team to identify real operational causes rather than inventing them from the graph.
When comparing multiple meters, decide whether they can legitimately be aggregated. Different tariffs, service points, legal accounts, or electrical boundaries may prevent one combined solar balance from representing billing or interconnection reality.
Keep energy overlap separate from tariff economics
An interval load analysis can supply energy flows to a financial model, but cost depends on the applicable tariff and contract. Energy charges, demand charges, time periods, ratchets, fixed charges, export credits, taxes, riders, and eligibility rules may apply differently. Verify the live source and effective date for the customer’s service.
OpenEI maintains a Utility Rate Database as a public rate-information resource. Database entries can be helpful for discovery and modeling, but the serving utility’s current tariff, customer class, bill, and written confirmation remain the project source. Do not assume a database entry applies because the utility name matches.
Build a tariff evidence sheet:
- utility and exact rate schedule;
- customer class and eligibility basis;
- effective date and source URL or document;
- billing determinants used by the model;
- treatment of imports, exports, demand, fixed charges, and other applicable components;
- items deliberately omitted;
- review and expiry date.
Show energy results before savings. That sequence lets a reviewer inspect physical assumptions without being distracted by currency outputs. It also makes tariff updates easier because the energy model can remain stable when only billing logic changes.
Compare peak demand with the right time definition
Commercial customers may ask whether solar reduces demand charges. The answer depends on how the tariff defines demand, when the facility peak occurs, the billing interval, seasonal or time-of-use windows, ratchets, and the coincidence of PV output with the measured peak. Annual energy matching cannot answer that question.
Identify the highest relevant demand intervals under the tariff logic, then inspect those days and surrounding operations. A peak near midday may overlap with PV in one scenario. A peak after sunset will not be served by concurrent PV. Weather variability, outages, equipment schedules, and storage dispatch can alter modeled results.
Do not promise a demand-charge reduction from one historic period. Present the observed peaks, modeled PV contribution under declared assumptions, and sensitivity to relevant conditions. Let the financial reviewer apply the current tariff and contract logic.
Build a review page another person can challenge
A useful consumption-versus-solar review should allow a customer, designer, or financial reviewer to trace the result. Include:
- decision and site boundary;
- data provenance and coverage;
- time alignment and data-quality findings;
- baseline and forecast distinctions;
- proposed PV configuration and production assumptions;
- monthly energy-flow table;
- operating-pattern visuals and exceptions;
- tariff source and financial-model boundary;
- open questions and sensitivity cases;
- version references shared with the proposal.
Solar Designing supports the proposed layout, Shadow Analysis supports shade inputs, and Solar Proposals carries customer-facing output. The energy analysis should use the same configuration and visible assumptions. Software can align records, but it cannot determine whether customer data is representative or a tariff applies.
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.
When is a load profile ready for use in a solar proposal?
A load profile is ready for proposal use when its site and meter identity, time basis, units, coverage, quality dispositions, operating representativeness, forecast assumptions, PV scenario, tariff boundary, and review status support the exact customer claim being shown. Measured, corrected, imputed, forecast, and modeled values must remain distinguishable, and every material change should trigger a new analysis and communication review.
Readiness is claim-specific. A cleaned historic profile may support a conversation about observed operating patterns while remaining inadequate for a future-load forecast, demand-charge statement, storage dispatch, or savings claim. The release record should name what the dataset supports rather than marking the entire file “approved.”
Use this proposal-release checklist:
- Confirm customer authorization, facility, service, meter, and channel identity.
- Confirm interval, time zone, units, coverage, and transformation lineage.
- Disclose missing, corrected, imputed, excluded, and abnormal periods.
- Record why the historical period represents or does not represent future operations.
- Separate observed baseline from customer-supplied forecast scenarios.
- Match production to the current layout, equipment, model, and interval convention.
- Keep energy overlap, demand, tariff, savings, and storage claims in their proper models.
- Reconcile proposal charts and values with the reviewed analysis revision.
- State material limitations beside the affected conclusion.
- Record the reviewer, customer question, and refresh trigger.
Use a release note:
Customer decision supported:
Consumption revision and observation period:
Measured and transformed-data status:
Forecast or operating-change assumptions:
PV and storage scenario revision:
Tariff and financial boundary:
Claims supported:
Claims prohibited or held:
Reviewer, date, and refresh trigger:
The financial assumptions audit provides the deeper check for tariff, escalation, financing, and savings inputs. This article owns the load and timing evidence that feeds those models; it does not validate the financial conclusion.
Archive the exact chart and values released to the customer. A later meter correction, operating forecast, layout change, production rerun, or tariff update should identify which earlier communication may be stale. Updating the internal workbook does not retract an old proposal automatically.
Finance, tariff, tax, contract, utility, privacy, electrical, storage, and customer-specific suitability questions remain human-review-only. The workflow improves data lineage and task completion; it does not guarantee consumption, production, demand, savings, or financial outcomes.
Before customer release, give the chart and review page to an analyst who did not prepare them. Ask that person to trace one visible peak, one data-quality flag, one forecast adjustment, and one production interval back to their source records without opening a private message or relying on the original analyst’s explanation.
The reviewer should also identify the meter boundary, time convention, current PV scenario, and claims the page does not support. If the chart makes modeled or imputed values look measured, revise its legend and nearby explanation.
Record the handoff result with the analysis revision. A returned page should name the missing source, ambiguous transformation, stale scenario, or unsupported claim so the correction improves the reusable review package rather than one presentation alone.
Reopen the analysis when the site or design changes
Refresh the review when new interval data arrives, the meter boundary changes, a facility alters operations, the array or equipment changes, shading evidence changes, storage is added, a tariff updates, or a customer corrects a material assumption. Record the delta rather than overwriting the old scenario.
Maintain an assumption register with owner, source, observation date, expiry or trigger, and affected output. Volatile items such as rates should have short review periods. Evergreen relationships can remain longer, but the site’s operating plan still deserves confirmation before a major decision.
A well-reviewed profile does not guarantee a project outcome. It gives the decision-makers a faithful picture of what was observed, what was modeled, where the two overlap, and which open conditions can still move the answer.
Test whether one year is doing too much work
One complete year is convenient because it covers seasons, but it can still contain unusual weather, maintenance, vacancy, new tenants, production changes, or temporary schedules. When additional years are available on the same meter basis, compare them before choosing a baseline. The purpose is not to average away real change. It is to see whether the selected period represents the operation the customer expects to continue.
Build a year-comparison page with monthly energy, maximum relevant demand, operating days, major known events, and data-quality flags. Keep weather normalization or other adjustments separate unless the method and source data have been reviewed. A chart that shows differing years may be more honest than one normalized line whose adjustments nobody can reconstruct.
Ask the facility team about the largest differences. A lower July may reflect a planned shutdown, metering gap, efficiency upgrade, or reduced production. Each explanation leads to a different baseline decision. Record the source of the explanation and whether documents support it.
For multi-meter sites, map the electrical and billing boundary before aggregation. Determine whether the proposed PV system can physically and contractually serve the loads being combined. Separate meters may sit behind different services or tariffs. A portfolio total can help corporate planning while remaining unsuitable for one interconnection or bill model.
Use a boundary table:
| Data series | Physical boundary | Billing boundary | Proposed PV relationship | Treatment |
|---|---|---|---|---|
| Main facility meter | Identified service | Current utility account | Direct comparison candidate | Include after validation |
| Tenant meter | Separate or submetered load | Owner or tenant billing | Depends on project arrangement | Keep separate until confirmed |
| EV charger forecast | Future equipment | Tariff path pending | Scenario only | Label forecast and schedule |
| Generator output | Behind-meter source | May alter net meter data | Must be separated if possible | Obtain channel definition |
If only net meter data exists behind other generation, the recorded profile may not represent gross facility use. State that limitation and obtain additional channels when the decision requires them. Do not add a generic correction factor.
This broader comparison can also expose a mismatch between customer language and the data. “The plant runs all week” may mean staff are present, while major electrical production runs on selected shifts. Treat the conversation as a clue, then verify it against intervals and operating records for the same observed period.
Review solar production and load assumptions together
Book a guided SurgePV demo to explore array layout, shading, energy-yield modeling, financial modeling, and proposal generation.
Book a guided demoFrequently Asked Questions
Why is annual electricity use insufficient for solar sizing?
Annual use shows total energy across a period, but it hides when the site consumed electricity. Solar generation varies through each day and season. Two sites with the same annual total can have different daytime overlap, export, peak demand, and tariff exposure, so interval data supports a more faithful comparison.
What interval length should a solar load analysis use?
Use the finest reliable interval available that matches the decision and can be aligned with the production model and tariff. Finer data can reveal short peaks, while coarser data may be adequate for early screening. Never invent resolution by spreading monthly totals into synthetic intervals without a visible method and limitations.
How should missing consumption intervals be handled?
Flag missing intervals, identify their dates and operating context, and decide whether the gap makes the period unrepresentative. Obtain replacement meter data where possible. If estimation is allowed, document the method, source periods, affected share, and sensitivity, then keep measured and imputed values distinguishable in the review record.
Does high solar self-consumption guarantee a good project?
No. Self-consumption is one modeled relationship between site load and PV output. Economics also depend on tariff structure, export treatment, demand charges, contract terms, financing, taxes, system cost, degradation, operations, and actual performance. Technical overlap should be reported separately from financial conclusions and customer objectives.
When should a load profile be refreshed?
Refresh it when the analysis period ages, the meter or account changes, operations, occupancy, equipment, production shifts, efficiency work, electrification, outages, or abnormal closures make the historic period less representative. Record the observation date and decide whether past data, a stated forecast, or multiple scenarios should drive the proposal.
Sources
Primary research and reference material used for this desk-research article.
Where this fits
This article is part of SurgePV's Solar Business & Operations hub, which works through the topic from first principles to the decisions a project team actually has to make.


