Nectar continuously monitors your utility data for unusual patterns. When something looks off — a sudden jump in consumption, an unexpected cost increase, or a fee you may not have noticed — it surfaces as an anomaly for your team to review.
Anomaly detection is not enabled by default. To get started, go to Settings > Company > Anomaly Detection, enable detection for the sites you want to monitor, and create a detection schedule. Detection only runs when a schedule is configured.
Anomaly types
Nectar detects four types of anomalies:
| Type | What it detects |
|---|
| Usage spike | A month’s consumption for a specific meter type is significantly higher than the seasonal average |
| Cost spike | A site’s total monthly bill cost is significantly higher than the seasonal average |
| Late fee | A bill contains interest or penalty charges above a minimum threshold |
| High demand charges | Electricity demand charges make up an unusually large share of the bill |
How the baseline works
For usage and cost spikes, Nectar builds a seasonal baseline from your recent billing history:
- Heating season covers October through March.
- Cooling season covers April through September.
Each month is compared against the average of the same season’s prior months. For example, a July bill is compared against previous cooling-season months (April–September), not against winter months when usage patterns are typically different.
The baseline uses up to two years of same-season history. Older data is excluded so that the baseline reflects your site’s current operating profile rather than outdated patterns.
Sustained changes are not anomalies
If usage or cost jumps and stays elevated for several consecutive months in the same season, Nectar recognizes this as a regime change — such as a new meter being added, a rate increase, or an operational change — rather than a one-time anomaly. These sustained shifts are automatically suppressed so that only genuine outliers are flagged.
Sensitivity levels
Each site can be configured with a detection sensitivity:
| Level | Behavior |
|---|
| Low | Only flags extreme spikes — good for sites with naturally variable usage |
| Medium | Balanced detection — the default for most sites |
| High | Flags smaller deviations — useful for sites where consistency is critical |
Multi-site bills
When a single utility bill covers meters at multiple sites, Nectar allocates cost to each site proportionally based on the meters’ usage. This ensures that a large multi-site bill doesn’t inflate any individual site’s cost baseline.
Reviewing and resolving anomalies
Navigate to Data Quality > Anomalies to see all detected anomalies. The triage inbox lets you:
- Filter by anomaly type, site, commodity, or status.
- Inspect each anomaly in the detail panel, including the trend chart and contributing bills.
- Resolve anomalies by marking them as addressed or dismissing them as not a real anomaly.
Resolved and dismissed anomalies are preserved for audit purposes and won’t be re-created on subsequent detection runs.
Running detection
Detection does not run automatically — you need to create a schedule first. Go to Settings > Company > Anomaly Detection to set up a recurring detection schedule. Once configured, Nectar runs detection at the scheduled frequency.
You can also trigger a manual detection run at any time from the anomalies page using the Run detection button.
Incomplete data and false positives
If the trend chart shows gaps or unexpectedly low months, the baseline data may be incomplete. An incomplete baseline can make normal months appear as spikes.
Unresolved bill issues
Bills with open issues — such as unmatched accounts — are excluded from both the chart and the baseline. If many historical bills have unresolved issues, the baseline is artificially low and recent months may be flagged as spikes even though the site’s actual usage is normal.
Fix: Go to Data Quality > Issues and resolve the open issues for the affected site. This restores the excluded bills to both the chart and the baseline. The next detection run will use the corrected data.
Sparse historical data
The algorithm needs at least six same-season months to build a reliable baseline. Sites with limited or patchy billing history may produce a baseline that doesn’t reflect the site’s actual operating profile — especially if the available months happen to include unusually low or high values.
Fix: Allow more billing history to accumulate. As data coverage improves, the baseline becomes more representative and false positives decrease.
Related pages
See also: Glossary — Anomaly, Glossary — Baseline 
