Meter detail

Navigate to Data Inventory > Meters and open a meter’s full page (for example from the meter sheet’s Open full page action, or by visiting /data-inventory/meters/<meter id>). The full page provides tabs for usage, coverage, account context, bills, connection context, trends, and — when interval data exists — intervals.

​

Meter information and identifiers

The top sections show Meter Information (key fields at a glance) and identifiers (account IDs, meter IDs, and other provider-specific numbers). Use Edit to change meter fields — including Display ID, an optional label for lists and the meter header, plus meter tags and meter custom attributes. For waste and fuel meters, Edit also includes container name, size, and units when the hauler bills by container service rather than weight. Use Manage identifiers to add or remove identifier rows. Values you set on custom attributes appear in Meter Information. Empty attributes stay hidden. Company admins define attribute names on Settings > Company > Data Collection.

​

Tabs

From the meters list, the Meter Sheet preview uses the same tabbed content in a compact layout.

​

Usage history

The usage history table lists usage entries over time.

​

Reassign usage

On the Usage tab, select usage rows and click Reassign usage to move them to another meter. Use this when cleaning up duplicates — for example, when a duplicate meter has usage records the meter you want to keep is missing.

​

Meter groups

A meter group is one physical meter recorded as more than one row after an identity change — usually because the utility reissued the meter number, or billing moved from a consolidated account onto individual accounts (or the reverse). One row is current. The others are superseded earlier identities. Each row keeps its own bills and identifiers, so historical documents still match the number printed on them. Usage history, coverage, and trends on the current meter include every identity in the group. A grey banner at the top of the meter sheet or full page tells you which role you are looking at:

• On a superseded meter: This meter has been linked to the current meter. View active meter opens that row. Unlink returns this row to a standalone meter.
• On the current meter: This meter has N earlier identities. Usage history, coverage, and trends include all of them. View group opens the Meter group table on the Coverage tab.

Open the Coverage tab to see the Meter group table — current vs superseded, identifiers, period covered, and bill counts.

​

When to link

Use Link to another meter when two rows are the same physical device and you want one continuous history without deleting anything. Typical cases:

• The utility reissued the meter number, but bills still come from the same utility
• Billing moved from a consolidated account onto individual accounts (or the reverse)
• A one-time uploaded spreadsheet backfills earlier months from the same utility as a live connection, with no overlapping days

Do not link when the two rows bill overlapping months — that double-counts. Overlapping series are a duplicate (or primary and fallback when grouping is enabled). Meters you link must have the same site and the same utility type. They can sit on different accounts — bills stay on the account they were billed to; only the meter history joins. Edits to site, tags, and most settings apply to the whole group. Make those changes on the current meter.

​

How to link

From Data Inventory > Meters, select rows and use Link meters to do the same in bulk. Selected meters must share a site and a utility type.

​

Unlinking

Unlink from the banner, the Meter group table, or Actions > Group > Unlink from group. The meter keeps its bills and identifiers. You can link it again later.

​

Primary and fallback

When different providers cover the same physical device — a utility meter (delivery / LDC) and a supplier meter, or landlord vs retailer — that is a duplicate. Mark as duplicate drops the extra series from usage. Primary and fallback is the same problem with gap-filling: keep both rows, group them on the site Meters tab, set one as Primary, and let the others fill days the primary missed. Usage prefers the primary. Missing days are filled from the fallback. Overlapping days are not added twice. Cost does not follow this preference — cost still comes from each bill as billed. Use the same treatment when an uploaded spreadsheet overlaps months already billed by a connection. Linking overlapping series would add both bills. This is different from a meter group (identifier or account change, no overlap). See Physical meter group. Grouping is an advanced feature — email support@nectarclimate.com if you need it enabled.

​

Link vs merge vs duplicate

​

Actions menu

Open Actions on the full page or meter sheet to: Clone meter creates a new meter record based on this one — useful when you need a separate meter with similar identifiers or site assignment. To move a meter to another site, use Reassign site from the meters list (row actions or bulk actions) — not the meter detail Actions menu.

​

How the Primary ID is determined

Every meter can have multiple identifiers — an account number, a meter serial number, a POD number, and so on. The Primary ID is the single utility identifier Nectar shows in the Primary ID column and uses for matching. Lists, sheets, and the meter header show Display ID when you have set one; otherwise they fall back to the Primary ID. Nectar resolves the Primary ID using a four-tier priority system:

​

Tier 1 and 2 — Account preferences

If the meter’s account has a primary identifier type configured (for example, set to “Account”), Nectar looks for an identifier of that type on the meter and displays its value. If no match is found, Nectar tries the account’s secondary identifier type. You can configure these preferences in the account detail page by clicking Edit and setting the Primary identifier and Secondary identifier fields.

​

Tier 3 — Standard ordering

If neither account preference yields a match, Nectar falls back to a global priority list. The first type in this list that exists on the meter becomes the Primary ID:

​

Tier 4 — Any identifier

If no identifier matches the priority list, Nectar displays the first available identifier with a non-empty value.

​

Placeholder

If a meter has no identifiers at all, the platform shows a contextual placeholder — for example, “Downtown HQ · Electricity” (combining the site name and utility type).

​

Example

A meter has three identifiers:

• If the account’s primary identifier is set to “Account” → Primary ID shows 12345-678-9
• If the account has no preference set → Primary ID shows MTR-A12345 (Meter is highest in the standard ordering)

Hover over the Primary ID column in any table to see a tooltip listing all identifiers and which one was selected.

​

Controlling which identifier is displayed

If the Primary ID column is showing the wrong identifier type (for example, an account number instead of a meter serial number), you can change it:

1. Navigate to Data Inventory > Accounts and open the account that owns the meter.
2. Click Edit on the account detail page.
3. Set Primary identifier to the identifier type you want displayed (for example, “Meter” to show meter serial numbers).
4. Optionally set Secondary identifier as a fallback type.
5. Save. All meters under this account will now display the chosen identifier type as their Primary ID.

If the account has no preference set (both are blank), Nectar uses the standard ordering — which puts Meter first, then POD, then Electric Choice, and so on.

​

Managing identifiers

Meters can have multiple identifiers that map to different systems and utility provider formats. When a new bill is processed, Nectar looks at the numbers on the bill and matches them against identifiers stored on each meter. If the numbers match, the usage data is linked to the meter automatically. The identifier you see in the Primary ID column is determined by the priority system described in How the Primary ID is determined.

​

Identifier types

A meter can have multiple identifiers. This helps when different bills reference the same meter using different numbers.

​

How identifiers affect bill matching

When Nectar processes a new bill, it extracts identifier values from the document and compares them against the identifiers stored on every meter in the company. The matching algorithm requires that:

1. All identifiers extracted from the bill must exist on the meter.
2. Any extra identifiers on the meter that were not extracted from the bill must appear somewhere in the bill document text.

This means that adding an identifier value to a meter that does not appear on the utility bills can prevent future bills from matching to that meter.

​

Best practices

• Add all identifier variations. If your utility prints the meter number differently on different bills (with or without dashes, with or without a prefix), add all variations as identifiers. This prevents Nectar from creating duplicate meters.
• Compare against the bill. Open the original bill PDF and compare the numbers on it against what is stored in Nectar. Incorrect identifiers are the most common cause of mismatched data.
• Do not use identifiers for categorization. Identifiers are for bill matching, not labeling. If you add a custom value like “Building A - Floor 3” as an identifier, Nectar will look for that string in every incoming bill and fail to match when it is not found. Use meter tags or meter custom attributes instead.
• Check identifiers when data is mismatched. If usage data is showing up under the wrong meter — or not matching to any meter at all — check identifiers first.

Click Manage Identifiers to open a form where you can add, edit, or remove any of these identifier types.

​

Changing a meter’s site assignment

If a meter is showing up under the wrong building, use Reassign site on Data Inventory > Meters (select the meter, then choose the action). This is a common fix during initial setup, when meters may have been auto-assigned based on incomplete information. What happens when you reassign:

• All of the meter’s usage data — past and present — moves to the new site immediately.
• Analytics for the old site will no longer include this meter’s consumption. If Building A was showing 50,000 kWh and you move a 10,000 kWh meter away, Building A now shows 40,000 kWh.
• Analytics for the new site will now include it. Building B gains that 10,000 kWh.
• This is not just a going-forward change — the entire history moves.

When to reassign:

• A meter was auto-assigned to the wrong building during onboarding
• Your portfolio has been reorganized and a building moved to a different site
• You are cleaning up data and realized a meter has been in the wrong place

​

Handling duplicate meters

The same physical device is sometimes billed by different providers — a utility (delivery / LDC) and a supplier, a landlord and a retailer, or an uploaded spreadsheet that overlaps a live connection. If both series count, site consumption is too high. Mark as duplicate drops the extra series from usage (cost still counts). Primary and fallback is the same problem with gap-filling: we prefer the primary and fill missing days from the other meter. If the meter number or billing account actually changed and the months do not overlap, link instead.

​

When to mark as duplicate

Use Mark as duplicate when two meters cover the same physical device and you need usage counted once. That is the default treatment. If grouping is enabled, primary and fallback does the same job and can fill gaps.

​

What happens to your data

When you mark a meter as duplicate:

• The meter’s usage data is excluded from site and portfolio analytics aggregations to avoid double-counting consumption.
• Bill costs are still included in analytics — even if some meters on a bill are marked as duplicate, the bill’s total charges still contribute to cost reporting. Only usage (consumption) data is excluded.
• It is excluded from completeness tracking — it will not show as a gap.
• It is excluded from usage exports; cost exports retain the bill’s monetary records.
• Usage data is preserved — marking as duplicate is fully reversible. Click Unmark duplicate at any time to restore the meter to active status.
• Bills linked to the duplicate meter still appear in Data Inventory but their usage data does not contribute to consumption totals.

​

Resolving a duplicate

1. Identify the meter to keep — the one with the most complete data and the correct identifiers.
2. Click Mark as duplicate on the extra meter — this excludes its usage from consumption, emissions, and completeness while retaining bill cost.
3. Reassign usage if needed — if the extra meter has usage records the keeper does not have, use Reassign usage on the Usage tab before marking as duplicate.
4. Update identifiers on the meter you kept — add any identifier variations from the extra meter so future bills match correctly.

You can mark meters as duplicate individually from the meter detail Actions menu, or in bulk from the meters list by selecting multiple meters and choosing Mark as duplicate.

​

Merging meters

Merge meters combines two or more meter records into a single surviving record. Use merge only when Nectar created accidental twins — same account, same identifiers, same utility, two rows that should have been one. A meter-number or billing-account change is linking, not a merge.

​

Requirements

• All selected meters must belong to the same account and the same utility type.
• The merge is initiated from the meters list by selecting rows and choosing Merge meters.
• Merges cannot be undone.

​

Merge preview

Before confirming, a merge preview compares the selected meters:

• Identifiers — All identifiers from all meters are combined. Duplicates (same type and value) are kept once.
• Coverage — A before/after comparison shows how the merged meter’s data completeness improves.
• Usage data — Total usage records across all meters are counted.
• Primary meter selection — You choose which meter is the “primary” — the one that survives. The other meters are removed.

​

What happens after a merge

• The primary meter keeps its ID, site assignment, and account association.
• All identifiers from the secondary meters are added to the primary (unless they already exist).
• All usage data and bills from the secondary meters are reassigned to the primary meter.
• The secondary meters are removed. Use Link meters instead when you need to keep every row as an earlier identity.
• The Primary ID may change after a merge if the newly combined identifier set causes a different identifier to win the priority resolution.

​

When to merge vs. mark as duplicate

Prefer Link meters when the identifier or billing account changed and you want to keep every row. Use merge when two rows are accidental twins on the same account. Use Mark as duplicate — or primary and fallback when grouping is enabled — when different providers overlap, or when an upload overlaps a connection. Duplicate and fallback are the same double-counting problem.

​

Reading trends

Use the Trends tab for a calendarized usage chart. Spikes, drops, gaps, and seasonality are easier to see over time than in a single bill row:

• Sudden spikes may indicate a data extraction error, a rate change, or a real operational issue (for example a heating system running continuously).
• Sudden drops could mean a missing bill, an extraction that missed usage data, or a real reduction in consumption.
• Gaps mean there are no usage records for that period — usually a bill is missing or has not been processed yet.

​

Tips

• Check site assignments after onboarding. The most common data issue in Nectar is a meter assigned to the wrong building. Spend a few minutes after initial setup verifying each meter is under the correct site.
• Add all identifier variations. If your utility prints the meter number differently on different bills (with or without dashes, with or without a prefix), add all variations as identifiers. This prevents Nectar from creating duplicates.
• Resolve duplicates promptly. Duplicate meters cause double-counting. The longer they exist, the more data accumulates under both records, making cleanup harder.
• Use the Trends tab and usage table together. A sudden spike, drop, or gap is worth investigating — it could be a data issue or a real operational event.

​

FAQ