> ## Documentation Index
> Fetch the complete documentation index at: https://nectarclimate.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Glossary
> In-depth definitions for every term, field, and concept in the Nectar platform — organized by domain and searchable.
Need help in this area? See [Get Started FAQ](/docs/platform/getting-started-faq).
Every term you encounter in the Nectar platform, API, and documentation is defined here. The glossary is organized into **domain sections** so you can quickly find the terms relevant to what you're working on.
**Search tip:** Use **Cmd+K** (Mac) or **Ctrl+K** (Windows) to search the entire documentation —
including this glossary — by keyword.
***
## Domain index
Bills, dates, source types, flags
Charges, credits, taxes, balance
Meters, identifiers, usage, demand
Account numbers, statuses, tracking
Connection types, statuses, sync
Sites, companies, organizations
Electricity, gas, water, waste, fuel
EUI, site energy, benchmarking
GHG, CO₂e, scopes, emission factors
Calendarization, proration, attribution
Issues, Completeness, and Savings
Quick export, integrations
API keys, webhooks, sandbox
***
## Bills and Documents
A **bill** is a single processed utility document — the foundational unit of data in Nectar. Every bill is associated with an [account](#account), belongs to a [meter](#meter), and contains charges and usage data for a specific [billing period](#billing-period).
**API vs. UI terminology.** The platform UI calls these **bills**. The Nectar external API calls
them **documents**. They refer to the same entity.
***
### Bill
A single processed utility document. A bill contains the [billing period](#billing-period) start and end dates, total charges, usage quantities, [line items](#line-item), and optionally a link to the original PDF. Bills enter Nectar through three paths: an automated [connection](#connection), a manual [upload](#upload), or [manual entry](#manual-entry).
**Key fields:**
* [Bill date](#bill-date) — the billing period end date
* [Due date](#due-date) — payment deadline
* [Invoice ID](#invoice-id) — the utility's bill identifier
* [Source type](#source-type) — how the bill entered Nectar
* [Total charges](#total-charges-field) — the total amount billed
* [Summary bill flag](#summary-bill) — whether this bill covers multiple sub-accounts
**Related docs:** [Bills overview](/docs/platform/data-inventory/bills), [Bill detail](/docs/platform/data-inventory/bill-detail)
***
### Data quality issue
A **data quality issue** detected on a specific bill or meter — for example, a potential duplicate, missing usage data, an unmatched account, or an illegible scan. Each issue has a **type** describing the problem and a **severity** (error or warning). Open **View** on the bill or meter alert to see the **Issue sheet**, then resolve from the header **Resolve** dropdown. Work through a queue in [**Data Quality > Issues**](https://dash.nectarclimate.com/data-quality/issues).
A record with an open issue still shows its values — usage, dates, and allocated cost stay visible, marked with an amber warning triangle in the row's actions and a dotted amber underline on the value the issue is about. What an issue can withhold is the record's contribution to analytics, and that depends on what the issue is about:
* **Issues about a bill** withhold that bill's usage and cost from analytics and exports until resolved. Examples: potential duplicate, potential usage duplicate, unmatched account, no usage data, illegible/non-utility bill, account/meter mismatch, and inferred dates or units.
* **Issues about a meter** do not withhold usage. Examples: low confidence site match, assumed container size.
Data completeness always counts a bill as received, even when it has an open issue — so a period can show as complete while its usage is withheld from analytics. When all issues on a record are resolved, its data is included in analytics again. See [When is data excluded from analytics?](/docs/platform/data-quality/issues#when-is-data-excluded).
**Severity / flag type** (UI tone only — does not determine exclusion):
* **Action required** (error severity) — The data cannot be trusted until the issue is resolved. Examples: potential duplicate, unmatched account, no usage data, illegible bill, non-utility bill, account/meter mismatch.
* **Review and verify** (warning severity) — The data was inferred rather than extracted directly. It may be correct, but you should verify. Examples: date inferred, units inferred, assumed container size, low confidence site match.
**See also:** [Data quality](#data-quality-validation), [Flagged bill](#flagged-bill), [Anomaly](#anomaly)
**Docs:** [Issues triage](/docs/platform/data-quality/issues), [Bill detail — Data quality issues](/docs/platform/data-inventory/bill-detail#data-quality-issues)
***
### Bill date
The **last date** of the billing period covered by a bill. Also called the **service end date** or **statement date**. Nectar uses the bill date as the primary date for bill inventory sorting and many time-series analytics views. Some filters and exports use the service period or a month range instead — for example, Completeness and some data-export date modes.
**Why it matters:** The bill date determines where a bill appears in your data timeline. For trend analysis, Nectar often aligns bills by their bill date across accounts.
**Example:** A bill with a billing period of December 1–31 has a bill date of December 31.
***
### Billing period
The **start and end dates** covered by a single bill. The billing period represents the window of time during which the utility measured energy consumption that appears on this bill.
**Why it matters:** Billing periods vary by utility — most are monthly, but some utilities bill bi-monthly or quarterly. Overlapping billing periods between two bills for the same meter are flagged as a [data quality issue](#data-quality-issue).
**Relationship to bill date:** The bill date is always the last day of the billing period.
***
### Document
The external API term for a [bill](#bill). The platform UI uses "bill"; the [Nectar API](/docs/developer-guide/getting-started) uses "document." They refer to the same entity.
***
### Due date
The **payment deadline** printed on the bill. Not all utilities include a due date. When present, it is extracted by Nectar's AI processing and stored alongside the other bill fields.
**Note:** On bill detail, the due date is informational. When Bill Pay is enabled, due date also drives [late-risk level](#late-risk-level) (**Warning**, **Urgent**, or **Critical**).
***
### Invoice ID
The **unique identifier** for a bill as assigned by the utility provider. Also called the **invoice number**, **statement number**, or **document reference number**. Invoice IDs vary widely in format across utilities — some use numeric sequences, others use alphanumeric codes.
**Why it matters:** Nectar uses the invoice ID to detect and prevent duplicate processing — if the same invoice ID is encountered twice for the same account, the second instance is flagged as a potential duplicate.
***
### Summary bill
A summary bill **aggregates charges from multiple sub-accounts or service addresses** into a single document. Some large enterprise or multi-site customers receive a single consolidated bill from their utility that covers many meters or locations.
**Why it matters:** Summary bills require special handling in analytics and export — the charges represent many sites, not just one. Individual sub-account bills may also exist alongside the summary bill (each covering a single meter).
**When to set this:** Mark a bill as a summary bill if it covers multiple accounts. Treat summary bills carefully in per-meter analysis — charges often represent many sites — and retain them for portfolio-level totals.
***
### Source type
How a bill **entered Nectar**. The source type determines the bill's data provenance and is shown in the Bills table and bill detail view.
| Source type | Meaning |
| ----------------------- | ------------------------------------------------------------- |
| **Automated (Scraper)** | Collected by Nectar's scraper logging into the utility portal |
| **Email Forwarding** | Received via a forwarded bill email |
| **Manual Upload** | Uploaded as a PDF or CSV by a user |
| **Manual** | Data entered directly by a user |
| **Smart Meter** | Data provided by a utility's smart meter API |
| **API** | Data submitted via the Nectar API |
**Why it matters:** Source type affects your confidence in the data. Automated bills are collected directly from the utility portal. Manually entered data may contain human error.
***
### Flagged bill
A bill **marked for review** because of a suspected data quality issue. Bills are flagged automatically via [data quality issues](#data-quality-issue) — specific, typed anomalies detected during processing — or manually by a team member using the flag icon.
**Resolution:** Open the bill or meter alert to view the **Issue sheet**, resolve from the header **Resolve** dropdown, or use the [Issues triage inbox](/docs/platform/data-quality/issues) to work through multiple flagged bills.
**See also:** [Data quality issue](#data-quality-issue), [Data quality](#data-quality-validation)
***
### Bill pay status
The **routing and payment status** of a bill within your company's bill pay workflow. Possible customer values: **Unvalidated**, **Validated**, **Pending Routing**, **Delivered**, **In Exception**, **In Dispute**, **Funding Requested**, **Funding Received**, **Payment Processing**, **Payment Failed**, **Paid**, **Refunded**, **Archived**, **Cancelled**, and **No Payment Required**. Bill pay status is only shown when your company has bill pay routing enabled.
**See also:** [Routing rule](#routing-rule), [Routing decision](#routing-decision), [Destination](#destination)
**Docs:** [Bill Pay overview](/docs/platform/bill-pay/overview), [Funding overview](/docs/platform/bill-pay/funding)
***
### Routing rule
A rule that determines **where a bill is forwarded** after processing. Each rule has conditions (e.g., total charges above a threshold, specific utility provider, or site) and actions (forward via email, route to an AP integration, or notify a user). All matching rules fire — actions are deduplicated so each destination only receives the bill once.
**See also:** [Destination](#destination), [Routing decision](#routing-decision), [Bill pay status](#bill-pay-status)
**Docs:** [Bill Pay Rules](/docs/platform/bill-pay/rules)
***
### Destination
A **routing target** for processed bills. Destinations can be **email addresses** (the bill is forwarded as an email attachment) or **AP integrations** (the bill is routed to an ERP system). Each company can set a **catch-all destination** for bills that don't match any routing rule.
**See also:** [Routing rule](#routing-rule), [Routing decision](#routing-decision)
**Docs:** [Bill Pay Destinations](/docs/platform/bill-pay/destinations)
***
### Routing decision
The **logged result** of evaluating a bill against the company's routing rules. Each decision records which rule matched, what actions were taken (forwarding, tagging, notifications), and whether each action was delivered successfully. Decisions provide a complete audit trail of bill routing.
**See also:** [Routing rule](#routing-rule), [Additional forward](#additional-forward), [Bill pay status](#bill-pay-status)
**Docs:** [Bill audit](/docs/platform/bill-pay/decisions)
***
### Additional forward
A **manual send** of a bill to a different destination after the rule engine has made its initial routing decision. Additional forwards are recorded in the audit log and trigger delivery of the bill to the chosen destination without undoing previous actions.
**See also:** [Routing decision](#routing-decision), [Destination](#destination)
***
### GL code
A **general ledger classification** assigned to a bill during bill pay routing. GL codes can be assigned automatically by GL coding rules or manually from the routing history view. Each bill can have one GL code that identifies the cost category or department for accounting purposes.
**See also:** [Routing rule](#routing-rule), [Routing decision](#routing-decision)
**Docs:** [Bill Pay Rules](/docs/platform/bill-pay/rules)
***
### Late-risk level
An **escalation tier** indicating how close a bill is to its due date without being paid or delivered. Three levels exist: **Warning** (approaching due date), **Urgent** (close to due date), and **Critical** (payment is overdue or imminent). Late-risk levels trigger notifications to configured recipients so your team can take action before incurring late fees.
**See also:** [Bill pay status](#bill-pay-status), [Routing rule](#routing-rule)
**Docs:** [Funding overview](/docs/platform/bill-pay/funding)
***
### Revised bill
A bill with at least one usage row linked as a **revision** to a newer bill (`Revised` chip), or a bill that revises usage from earlier bills. Superseded usage is excluded from usage and emissions totals, while the earlier bill's original site relationships remain available for cost attribution. Both bills remain monetary records; credits determine their combined spend.
**Why utilities issue corrections:** Meter read errors, estimated reads that were later corrected, rate adjustments.
Do not confuse with **Revision history** (edit audit log) or utility email language like “rebill.”
**See also:** [Superseded usage](#superseded-usage), [Cost attribution](#cost-attribution)
**Docs:** [Bill detail — Revised bills](/docs/platform/data-inventory/bill-detail#revised-bills)
***
### Superseded usage
Usage on an earlier bill that has been replaced by usage from a correcting bill. It no longer contributes to usage, emissions, completeness, or usage-export totals, but it can retain the earlier bill's historical site cost attribution.
**See also:** [Revised bill](#revised-bill), [Usage data](#usage-data), [Cost attribution](#cost-attribution)
**Docs:** [Special situations — Revised bills](/docs/platform/methodology/edge-cases#revised-bills)
***
### Raw datasource name
Shown in the UI as **Raw provider name**. The **utility provider name extracted from the original bill** or utility portal — used as a fallback display string when a matched [datasource](#datasource) name is not available.
***
***
## Charges and Line Items
Every bill in Nectar breaks down its total amount into structured charge categories. Understanding these categories is essential for cost allocation, analytics, and reconciliation.
***
### Total charges
The **final total amount billed** for this period — the single number on the bottom of the bill. Total charges is the sum of all current charges, taxes, fees, and any balance carried forward from the prior period, plus credits (which are stored as negative values). This is the amount you would pay to settle the bill in full.
**Formula (simplified):** `Total Charges = Previous Balance + Current Charges + Tax Charges + Interest + Credits − Payments`
(Credits are added because they're stored as negative numbers; payments are subtracted because they're stored as positive numbers.)
Cost analytics and Cost Management use [net current charges](#net-current-charges), not this invoice-total formula.
***
### Current charges
The **gross charges for this billing period only**, before tax and credits are applied — the cost of energy consumed during this period. Current charges typically include the energy charge, demand charge (if applicable), distribution charge, and other recurring service charges.
**This is a gross figure.** Tax charges and credits are tracked as separate top-level fields on the bill and are not included here.
**Contrast with [net current charges](#net-current-charges):** Current charges + Tax Charges + Credits = Net Current Charges.
***
### Net current charges
The **actual amount this bill adds to your spend for the period**, calculated as `Current Charges + Tax Charges + Credits` (or equivalently `Total Charges − Previous Balance + Payments`). This is the headline figure on the bill detail "Charges Breakdown" panel and the per-bill cost used everywhere in cost management — trends, comparisons, \$/unit, and account analytics.
**Why it matters:** when a customer asks "what did this bill actually cost us?", net current charges is the answer. Total Charges can be inflated by an unpaid prior balance; current charges (gross) doesn't reflect taxes or credits.
***
### Credits
**Reductions to the amount owed** — utility rebates, billing adjustments, rate corrections, or returns of deposit. Credits are **stored as negative values** in Nectar, so a \$45 rebate appears as `credits = -45.00`. The bill detail UI renders them with a leading minus sign so it's visually clear they reduce the total.
A credit with a large magnitude relative to the bill total may indicate a billing error, a misclassified line item, or a prior-period adjustment.
**Example:** A utility credit of `-$45.00` for demand response event participation.
***
### Tax charges
**Government-mandated taxes and surcharges** applied to the bill. Tax charges vary by jurisdiction and utility type. Examples include state sales tax on electricity, municipal utility tax, or renewable portfolio standard (RPS) surcharges.
***
### Interest charges
**Late-payment penalties or financing charges** added when a prior balance was not paid by the due date. Most commercial utility accounts have interest provisions.
***
### Previous balance
The **unpaid balance carried forward** from the previous billing period. If the prior bill was not paid in full, the remaining amount appears here.
***
### Payments received
**Payments credited by the utility** since the previous bill was issued. Reduces the current open balance.
***
### Current open balance
The **total currently owed**, calculated as Previous Balance + Current Charges − Payments. This is the amount on which the [due date](#due-date) applies.
***
### Electricity supply charges
The **cost of electricity generation or commodity** — the energy itself, separate from the cost of delivering it to your building. In deregulated electricity markets, supply and delivery are often billed by different companies.
***
### Electricity delivery charges
The **cost of delivering electricity from the grid to your building**, covering local distribution infrastructure (power lines, transformers, substations). Also called the **distribution charge**.
***
### Distribution charge
A line item covering the **cost of distributing energy from the regional grid to your building** — the "last mile" of infrastructure. For electricity, this includes local power lines and substations. For natural gas, this includes the local pipeline network. Contrast with the **transmission charge**, which covers the high-voltage long-distance portion.
***
### Transmission charge
A line item covering the **cost of transporting high-voltage electricity** from power plants across the regional grid to local distribution systems. Transmission charges are typically a small fraction of the total bill.
***
### Demand charge
Charges on an electricity bill based on your **peak electricity consumption rate** (kilowatts, kW) during the billing period. The utility sizes its generation and transmission infrastructure to serve every customer's peak need — the demand charge recovers that capacity cost. Demand charges often represent 30–50% of a commercial electricity bill.
Also called: **electricity demand charges**, **capacity charges**, **peak demand charges**.
**See also:** [Peak demand](#peak-demand), [Demand meter](#demand-meter), [Billing demand](#billing-demand)
### Electricity demand charges
See [Demand charge](#demand-charge).
***
### Gas supply charges
The **cost of natural gas commodity** — the energy itself, separate from the delivery or transportation charge. In deregulated gas markets, supply may be purchased from a third-party supplier.
***
### Gas delivery charges
The **cost of transporting natural gas** through the local distribution network to your building. Also called the **distribution charge** for gas.
***
### Base charge
A **fixed monthly fee** on a utility bill that does not vary with usage. Also called a **customer charge**, **service charge**, or **minimum charge**. The base charge covers the utility's cost of maintaining the connection regardless of how much energy you consume.
***
### Fuel adjustment charge
A **variable surcharge** that reflects changes in the utility's cost of generating electricity, typically tied to natural gas or fuel oil prices. Also called the **fuel cost recovery charge** or **energy cost adjustment**. This charge fluctuates month to month and is passed through directly to customers.
***
### Line item
**Individual charge or credit components** within a bill. A single bill typically contains 5–20 line items: energy charges, demand charges, distribution charges, transmission charges, taxes, adjustments, and credits. Nectar extracts and categorizes line items, then aggregates them into the structured charge fields (current charges, tax charges, etc.).
**Why they matter:** Line items enable precise cost allocation — for example, separating supply costs from delivery costs, or isolating demand charges from energy charges.
***
***
## Meters and Usage Data
A **meter** is the device (or logical entity) that tracks utility consumption over time at a site. Meters accumulate data month after month and are the foundation for trend analysis, benchmarking, and emissions reporting.
***
### Meter
A physical device — or a logical entity corresponding to a service point in the utility's system — that records utility consumption at a [site](#site). Each meter tracks a single [commodity](#commodity). Meters are identified by a [meter identifier](#meter-identifier) extracted from utility bills.
**Key fields:**
* [Display ID](#display-id) — optional label shown in lists and sheets; falls back to the [Primary ID](#primary-id) when blank
* [Primary ID](#primary-id) — the resolved utility identifier
* [Meter identifiers](#meter-identifier) — all identifier values on this meter
* [Site](#site) — the location where the meter is installed
* [Account](#account) — the utility account associated with this meter
* [Utility type (commodity)](#commodity)
* [Tracking status](#tracked)
* [Meter tags](#meter-tag) for grouping
* [Address](#meter-address) — the service address on bills
* [Country](#meter-country) — the country of installation
**Related docs:** [Meters overview](/docs/platform/data-inventory/meters), [Meter detail](/docs/platform/data-inventory/meter-detail)
***
### Meter identifier
A **number or code stored on a meter** that Nectar uses to match incoming bills. Each meter can have multiple identifiers of different types — for example, a Meter number, an Account number, a POD number, and an ESI. Identifiers are extracted from utility bills during processing and stored on the meter record.
**Identifier types include:** Meter, POD, Electric Choice, Premise, Submeter, ESI, Choice ID, Sub-Account, Account, Summary Account, MPR, ICP, NMI, MIRN, and others. The full list depends on the utility provider and region.
**Why it matters:** Nectar uses identifiers to match bills to the correct meter. When a bill is processed, Nectar compares the numbers on the bill against all identifiers stored on each meter in the company. If the numbers match, the usage data is linked to that meter automatically.
Only add identifier values that appear on your utility bills. Adding custom labels or internal
codes may prevent future bills from matching correctly — Nectar expects every identifier on a
meter to appear in the bill document.
**Display:** Identifiers are always displayed in monospace font to prevent character confusion (e.g., 0 vs. O, 1 vs. l).
**See also:** [Primary ID](#primary-id), [Display ID](#display-id), [Meter](#meter)
**Docs:** [Meter detail — Managing identifiers](/docs/platform/data-inventory/meter-detail#managing-identifiers)
***
### Meter tag
A **company-defined label** you can assign to meters for organization and filtering. Meter tags are managed in **Settings** > **Company** > **Data** and can be assigned individually from the meter edit form or in bulk from the [meters table](/docs/platform/data-inventory/meters).
**See also:** [Meter](#meter), [Site tag](#site-tag)
**Docs:** [Meters — Row selection and bulk actions](/docs/platform/data-inventory/meters#row-selection-and-bulk-actions)
***
### Display ID
An optional **label** you set on a [meter](#meter). Lists, sheets, and the meter header use this Display ID when it is set. When it is blank, Nectar shows the [Primary ID](#primary-id).
Display IDs are for your team only. They do not change bill matching, duplicate detection, or how Nectar groups providers. Duplicate Display IDs are allowed.
Set a Display ID from **Edit** on the meter.
**See also:** [Primary ID](#primary-id), [Meter](#meter), [Name](#name)
**Docs:** [Meters overview](/docs/platform/data-inventory/meters), [Meter detail](/docs/platform/data-inventory/meter-detail)
***
### Name
An optional **label** you set on an [account](#account) or [connection](#connection). Lists, sheets, and detail headers use this name when it is set. When it is blank, Nectar shows the usual derived label: the [account number](#account-number) for accounts, or the utility provider name for connections.
For meters, the equivalent field is [Display ID](#display-id).
Names are for your team only. They do not change bill matching, duplicate detection, or how Nectar groups providers. Duplicate names are allowed.
Set a name from **Edit** on the account or connection.
**See also:** [Display ID](#display-id), [Account](#account), [Connection](#connection)
**Docs:** [Accounts overview](/docs/platform/data-inventory/accounts), [Connections](/docs/platform/data-input/connections)
***
### Primary ID
The **single utility identifier** Nectar resolves for a meter — used in the Primary ID column, matching, and exports. Lists and sheets show [Display ID](#display-id) instead when you have set one. Because a meter can have many [identifiers](#meter-identifier) of different types, Nectar chooses which identifier to show using a four-tier priority system:
1. **Account primary identifier** — If the meter's [account](#account) has a **primary identifier type** configured (for example, "Account" or "Meter"), Nectar looks for an identifier of that type on the meter and displays its value.
2. **Account secondary identifier** — If no match was found for the primary type, Nectar tries the account's secondary identifier type.
3. **Standard ordering** — If neither account preference matches, Nectar falls back to a global priority: Meter, POD, Electric Choice, Premise, Submeter, ESI, Choice ID, Sub-Account, Account, Summary Account, MPR, ICP, NMI, MIRN. The first type that exists on the meter wins.
4. **Any identifier** — If no identifier matches the priority list, Nectar displays the first available identifier with a non-empty value.
If a meter has no identifiers at all, the platform shows a contextual placeholder — for example, the site name and utility type ("Downtown HQ · Electricity").
**Why it can change:** Adding or correcting an identifier on the meter, changing the account's primary or secondary identifier settings, or processing a bill that supplies a new value for a preferred type can all change which value is selected — even when the meter itself is the same record.
**Why it matters:** The Primary ID is the utility's identifier, not a custom label. To show a friendly or internal label in lists, set [Display ID](#display-id) on the meter. To change *which* identifier appears as Primary ID, set the account's primary identifier type in the [account detail](/docs/platform/data-inventory/account-detail).
**See also:** [Display ID](#display-id), [Meter identifier](#meter-identifier), [Account](#account), [Meter](#meter), [Account number](#account-number)
**Docs:** [Meter detail — How the Primary ID is determined](/docs/platform/data-inventory/meter-detail#how-the-primary-id-is-determined), [Account detail](/docs/platform/data-inventory/account-detail), [Meters overview](/docs/platform/data-inventory/meters)
***
### Tracked
Whether Nectar is **actively collecting and processing new bills** for a meter. When tracked, every new bill that arrives through the associated connection is matched to this meter. When untracked, historical data is retained but new bill collection stops.
**When to untrack:** Meters that are no longer active at a site (equipment removed, tenant moved out) should be untracked to keep your data clean.
An untracked meter is left out of analytics totals, but it still takes its own share of any bill it appears on — so its rows show an allocated cost, and its tracked siblings on that bill are not charged for it. See [Cost allocation](/docs/platform/methodology/cost-attribution#how-a-bill-is-split-across-meters).
***
### Meter address
The **service address** associated with this meter, as printed on utility bills. This may differ from the site address if the utility uses its own address format for the service point.
***
### Meter country
The **country where this meter is located**. Used when calculating greenhouse gas emission factors for [Scope 2 emissions](#scope-2-emissions), since electricity grid emission factors vary significantly by country and region.
***
### Demand meter
A meter that records **peak electricity demand (kW)** in addition to consumption (kWh). Demand meters are common for commercial and industrial electricity accounts and are required to calculate [demand charges](#electricity-demand-charges).
**Interval:** Demand is typically measured as the highest 15- or 30-minute average during the billing period.
***
### Usage data
The **time-series consumption records** associated with a meter — how much energy was consumed during each billing period. Usage data is the primary input for analytics, trend analysis, and emissions reporting.
**Fields per usage record:**
* Start date and end date of the consumption period
* Usage quantity (e.g., 1,200 kWh)
* Unit of measure (e.g., kWh, therms, gallons)
* Commodity type
* Additional data fields (optional free-form key-value metadata)
***
### Interval data
**Sub-hourly electricity readings** — typically 15-minute or 30-minute intervals. Interval data is collected from smart meters and utilities that provide it via API or automated download. Interval data enables detailed analysis of load profiles, peak demand timing, and time-of-use cost optimization.
***
### Document count
The **total number of processed bills** associated with a meter. A growing document count indicates ongoing active collection.
***
### Last bill date
The **bill date of the most recently processed bill** for a meter or account. Useful for verifying that data collection is current — if the last bill date is several months ago, the connection may need attention.
***
***
## Accounts
An **account** is the billing relationship between your organization and a utility provider — identified by an account number. Accounts are discovered automatically when Nectar logs into a utility portal.
***
### Account
A utility account linked to a [connection](#connection). Accounts have a unique [account number](#account-number), belong to exactly one connection, and are associated with one or more [meters](#meter). Accounts are the intermediate entity between connections (which come from a single portal login) and meters (which track individual service points).
**Key fields:**
* [Name](#name) — optional label shown in lists and sheets; falls back to the [account number](#account-number) when blank
* [Account number](#account-number)
* [Status](#account-status)
* [Tracking](#tracked)
* [Site (from meters)](#site-from-meters)
***
### Account number
The **identifier printed on utility bills** that uniquely identifies the account at the utility provider. Nectar extracts the account number from bills and uses it for matching.
**Display:** Account numbers are always displayed in monospace font.
***
### Account status
The **lifecycle state of an account** in Nectar. The platform displays plain-language labels for each status.
| Status | Meaning |
| -------------------- | ------------------------------------------------------------------------------------------------------ |
| **New** | Nectar found this account in the utility portal but it has not yet been linked to a site or confirmed. |
| **Onboarded** | The account has been confirmed and linked to a site. Awaiting first data collection. |
| **Active** | The account is fully connected and Nectar is collecting bills and usage data normally. |
| **Closed** | Previously active but no longer in use. Historical data is retained. |
| **Duplicate** | Nectar detected this appears to be a duplicate of an existing account. |
| **Error** | An unexpected error occurred during data collection for this account. |
| **Download Failed** | Nectar was unable to download one or more documents from the utility portal for this account. |
| **Not Found** | The account could not be located in the utility portal. |
| **No Documents** | Nectar logged in successfully but found no documents available for this account. |
| **Connection Issue** | The connection associated with this account is experiencing problems. |
| **Company Inactive** | The company that owns this account has been deactivated in Nectar. |
| **Disabled** | Tracking has been turned off for this account. |
***
### Site (from meters)
The site associated with an account, **derived from the site assignments of its meters**. Since meters (not accounts) are directly assigned to sites, the account inherits its site from its meters. If an account has meters at multiple sites, the primary site is shown.
***
### Last sync
The **last time Nectar checked this account on the utility portal** for new bills. For online connections, this happens automatically on a weekly schedule.
***
### Last service date
The **date when the account was closed by the utility**. This represents the end date of the final meter reading for the account. A null value indicates the account is still active with the utility.
***
***
## Connections
A **connection** is the configured link between Nectar and a utility provider. It holds the credentials, settings, and schedule for automated bill collection.
***
### Connection
A configured link between Nectar and a utility provider. Each connection has a [datasource](#datasource) (the utility), login credentials, one or more associated [sites](#site), and a [connection status](#connection-status). Connections are the engine that drives automated data collection.
**Key fields:**
* [Name](#name) — optional label shown in lists and sheets; falls back to the utility provider name when blank
**Connection types:**
* [Online connection](#online-connection) — Nectar's scraper logs in automatically
* [Email connection](#email-connection) — bills arrive via forwarded email
***
### Occupancy adjustment
A feature that **multiplies raw usage values by a percentage** to reflect partial building occupancy. When your organization occupies only a portion of a building, the occupancy percentage adjusts your usage data so analytics, exports, and cost attribution reflect only your share. Configured at the site level with three application modes: disabled, all data, or per connection.
**See also:** [Site](#site), [Usage data](#usage-data)
**Docs:** [Occupancy adjustment](/docs/platform/methodology/occupancy)
***
### Online connection
A connection type where **Nectar's automated scraper logs into the utility portal** using the credentials you provide, just like a person would. Nectar checks for new bills on a weekly schedule and downloads them. This is the most common connection type, supported for thousands of utility providers.
***
### Email connection
A connection type where **bills are collected by forwarding utility emails** to a Nectar-provided email address. When a bill email arrives, Nectar automatically processes the attached document.
**When to use:** For utilities where portal login scraping is not available, or where bills are only delivered by email.
***
### Connection status
The **current operational state** of a connection. The underlying **status code** is the same in the app and in API responses — for example `CONNECTED` or `PENDING`. The platform shows **plain-language labels** for those codes; a few are shortened in the UI.
| Status | What it means | What to do |
| --------------------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Connected** | Everything is working normally. Nectar is collecting data on its regular weekly schedule. | Nothing — you're good. |
| **Pending** | The connection was just created and is waiting for its first collection run. | Sit tight. The first collection usually finishes within a few hours; in some cases it can take up to 48 hours. |
| **Under Investigation** | The Nectar team is actively looking into an issue with this connection. | No action needed on your end. The team will resolve it or reach out if they need information. Email [support@nectarclimate.com](mailto:support@nectarclimate.com) if you'd like an update. |
| **Password Incorrect** | The utility website rejected the login credentials. This usually means the password was changed recently. | Update the password using the **Reconnect** action with the current utility login. If the password was changed on the utility site, enter the new one. |
| **MFA Token Expired** | Automated login can’t complete MFA — codes aren’t reaching Nectar or the MFA session expired. | Use **Reconnect** to open **MFA forwarding** setup (email or SMS forwarding), confirm, or turn off MFA if the portal no longer requires it. |
| **New Password Needed** | The utility website is forcing a password reset before allowing login. | Go to the utility website directly, reset the password, then reconnect in Nectar with the new password. |
| **Additional Credentials Needed** | The portal is asking for extra verification — security questions, a PIN, or additional identity confirmation. | Use the **Reconnect** action and answer the prompts. |
| **Website Down** | The utility provider's website is temporarily unavailable. | No action needed. Nectar will automatically retry on the next weekly check. This resolves on its own. |
| **No Accounts Found** | Nectar logged in successfully, but didn't find any utility accounts in the portal. | Log into the utility website yourself and confirm accounts are visible. If they are, contact [support@nectarclimate.com](mailto:support@nectarclimate.com). |
| **URL Inaccessible** | The utility portal URL is unreachable — the site may have moved, been taken down, or blocked Nectar's requests. | Verify the URL still works in a browser. If it does, contact [support@nectarclimate.com](mailto:support@nectarclimate.com). |
| **Company Inactive** | Your company has been deactivated in Nectar, so connections cannot run. | Contact [support@nectarclimate.com](mailto:support@nectarclimate.com) to reactivate your company. |
| **Deactivated** | This connection has been deactivated. Data collection is stopped, but all historical data is preserved. | Open the actions menu on the connection and click **Activate connection** to restart data collection. |
| **Other Error** | Something unexpected happened that doesn't fit the categories above. | Contact [support@nectarclimate.com](mailto:support@nectarclimate.com) with the connection name and company. |
**See also:** [Connection](#connection), [Reconnection](#reconnection)
**Docs:** [Connections](/docs/platform/data-input/connections), [Connection statuses (API)](/docs/developer-guide/connection-statuses)
***
### Datasource
The **utility provider** a connection is linked to — for example, PG\&E, ConEdison, or Thames Water. Each datasource is a known entry in Nectar's provider catalog, including the portal URL, login flow, and commodity types supported.
***
### Collection start date
The **earliest date from which Nectar will retrieve historical bills** when a connection is first created. Most utility portals provide 12–24 months of history. You set the collection start date during the [connection wizard](/docs/platform/data-input/connection-wizard).
***
### Data owner
The **email address of a person responsible** for a connection or site's data. A data owner email is required when creating a connection — this person receives reconnection requests if credentials expire and data gap notifications when bills stop arriving. On a site, data owners are the primary recipients for data gap alerts. A site can have up to ten data owner email addresses.
***
### Reconnection
**Re-establishing a connection** that has entered an error state. Typically required when utility portal credentials expire (password change, MFA change, or portal security update). The reconnect flow updates credentials without losing historical data or site associations.
***
### Invitation
A **shareable link** that lets a recipient create a new utility connection — or reconnect an existing one — without a Nectar login. Invitations are the replacement for the legacy **magic link** system and add revocation, activity logs, email allow-lists, and resend.
**Two types:** **Contributor invitation** (creates a new connection) and **Reconnect invitation** (updates credentials on an existing connection).
**Security:** Each invitation is a revocable, time-bound token stored in Nectar's database. The recipient only sees the connection flow, never your other data. When `allowedEmails` is set, the recipient must verify one of those addresses before the link is redeemable.
See [Invitations](/docs/platform/data-input/invitations) for the end-user experience and [Connection invitations](/docs/developer-guide/connection-invitations) for the API.
***
### Magic link (deprecated)
A **legacy shareable URL** that let a recipient create or reconnect a utility connection without a Nectar login. Magic links have been replaced by [Invitations](#invitation), which add revocation, activity logs, email allow-lists, and resend. Existing magic links still work; new flows should use invitations.
***
***
## Sites and Organizations
**Sites** are the physical locations in your portfolio. **Companies** are logical groups of sites. **Organizations** are the top-level container for all companies and users.
***
### Site
A **physical location** — a building, warehouse, storefront, data center, or other facility — where utility accounts are active. Sites have a real-world address and are the central organizing unit for all data in Nectar. Meters, accounts, and bills are all ultimately associated with sites.
**Key properties:**
* Physical address
* [Site tags](#site-tag) for grouping
* Associated meters and accounts
* [Completeness](#completeness) coverage for data quality
***
### Site tag
A **label assigned to sites** for grouping and filtering. Site tags let you organize sites by region, portfolio, building type, ownership structure, or any other categorization relevant to your organization. You can filter by site tag across Data Inventory, Analytics, and Data Export.
***
### Company
A **logical grouping of sites and connections** within an organization. A company typically represents a client you manage, a business unit within an enterprise, or a portfolio of buildings. All data in Nectar is scoped to a company — you select the active company from the sidebar.
***
### Organization
The **top-level account structure** in Nectar. An organization contains all companies, users, and settings for a Nectar customer. Organization-level settings include API key management, webhook endpoints, and white-label branding.
***
### Gross floor area (GFA)
The **total interior square footage** of a building, measured from the outside surfaces of exterior walls. GFA is used as the denominator when calculating [Energy Use Intensity (EUI)](#energy-use-intensity-eui). GFA typically includes all interior spaces — offices, hallways, stairwells, mechanical rooms, and storage areas — but excludes exterior spaces such as parking lots.
**Note:** GFA is entered and managed in platform settings for sites configured for ENERGY STAR benchmarking.
***
***
## Commodities and Energy Types
Nectar tracks multiple **commodity types** — the type of utility measured by each meter.
***
### Commodity
The **type of utility** tracked by a meter or bill. Nectar supports eleven commodity types:
| Commodity | Description | Typical units |
| ----------------- | ------------------------------------------------------- | ---------------------------------- |
| **Electricity** | Grid electricity | kWh, MWh |
| **Natural gas** | Piped gas from a distribution utility | Therms, CCF, MCF, kBtu |
| **Water** | Municipal potable, well, or reclaimed water (not sewer) | Gallons, CCF, cubic meters |
| **Sewer** | Wastewater / sewer discharge | Same volume units as water |
| **Waste** | Disposal and hauling services | Tons (mass or volume on source) |
| **Fuel** | Diesel, propane, kerosene, fuel oil | Gallons, liters |
| **Solar** | On-site photovoltaic generation | kWh |
| **District** | District steam, chilled water, hot water | Mlb, kBtu, ton-hours |
| **Refrigerant** | Refrigerant gases (HFCs, HCFCs) | Pounds, kg |
| **Telecom** | Telecom and related communications services | Service-period charges; units vary |
| **Miscellaneous** | Other utility or facility charges not covered above | Units vary by provider |
***
### Electricity
Grid electricity purchased from a utility, measured in **kilowatt-hours (kWh)** or megawatt-hours (MWh). Electricity bills often include both consumption (kWh) and [demand](#electricity-demand-charges) (kW) components.
***
### Natural gas
Piped gas from a distribution utility, measured in **therms**, **CCF** (hundred cubic feet), **MCF** (thousand cubic feet), or kBtu. The conversion: 1 therm = 100,000 BTU ≈ 1 CCF.
***
### Water
Municipal water consumption — potable, well, or reclaimed supply — measured in **gallons** (US) or **CCF** (hundred cubic feet). 1 CCF ≈ 748 gallons. Water analytics and water-only export paths include this commodity only, not sewer discharge.
**See also:** [Sewer](#sewer)
***
### Sewer
**Wastewater or sewer discharge** — usage billed separately from potable/reclaimed water supply. Sewer shares the same volume unit preferences as water. When a utility does not report sewer volumes directly, Nectar can [derive sewer usage from water consumption](#implied-metering).
**See also:** [Water](#water), [Implied metering](#implied-metering)
**Docs:** [Water and sewer edge cases](/docs/platform/methodology/edge-cases#sewer-and-water)
***
### Waste
Waste **disposal and hauling services**. Raw usage on bills may be reported by **mass or volume** (or estimated from container pickups). Each [waste material](#waste-material) carries a **density** that converts volume to mass. Nectar normalizes usage to US tons and displays it in your company's configured waste units.
**See also:** [Waste description](#waste-description), [Waste material](#waste-material), [Waste stream](#waste-stream), [Processing rule](#processing-rule)
**Docs:** [Waste tracking](/docs/platform/methodology/waste-tracking)
***
### Waste description
The **material label found on the source document** — for example, `OCC` or `MSW`. Nectar classifies that label into one of your company's [waste materials](#waste-material). Editing a meter's material does not rewrite its description. [Processing rules](#processing-rule) then assign the material to a [waste stream](#waste-stream) based on the hauler and, when needed, the site.
**See also:** [Waste material](#waste-material), [Waste stream](#waste-stream), [Processing rule](#processing-rule), [Waste](#waste)
**Docs:** [Waste tracking](/docs/platform/methodology/waste-tracking)
***
### Waste material
The **material category** of a waste record — for example, cardboard, organics, or mixed solid waste. Each waste material carries a **density** used to convert between volume and mass. Materials are classified from the [waste description](#waste-description) on documents and assigned to a [waste stream](#waste-stream) by a [processing rule](#processing-rule).
**See also:** [Waste](#waste), [Waste description](#waste-description), [Waste stream](#waste-stream), [Processing rule](#processing-rule)
**Docs:** [Waste tracking](/docs/platform/methodology/waste-tracking)
***
### Waste stream
The **processing method or end destination** of a waste record — for example, landfill, recycled, composted, or donated. A [waste material](#waste-material) is assigned to a stream by a [processing rule](#processing-rule).
**See also:** [Waste](#waste), [Waste material](#waste-material), [Processing rule](#processing-rule)
**Docs:** [Waste tracking](/docs/platform/methodology/waste-tracking)
***
### Processing rule
A rule that connects a [waste material](#waste-material) to a [waste stream](#waste-stream). Processing rules can be scoped **company-wide**, **provider-only** (all sites for one hauler), or **provider + site** — the most specific match wins, so the same material can route to different streams by hauler or site.
**See also:** [Waste material](#waste-material), [Waste stream](#waste-stream), [Waste](#waste)
**Docs:** [Waste tracking](/docs/platform/methodology/waste-tracking)
***
### Fuel
**Liquid and solid fuels** other than natural gas — including diesel, propane, kerosene, and fuel oil. Measured in gallons or liters. Fuel consumption is a common [Scope 1 emissions](#scope-1-emissions) source.
***
### Solar
**On-site photovoltaic (PV) generation**, measured in kWh. Solar data may appear as generation credits on an electricity bill ([net metering](#net-metering) arrangements) or as a separate solar production reading.
***
### District energy
**Centrally produced heating or cooling** distributed via underground insulated pipes. Types include:
* **District steam** — high-pressure steam for heating
* **District hot water** — heated water for space heating or domestic hot water
* **District chilled water** — chilled water for air conditioning
Measured in Mlb (thousand pounds of steam), kBtu, or ton-hours.
***
### Refrigerant
**Refrigerant gases** used in HVAC, refrigeration, and chiller equipment — including HFCs (hydrofluorocarbons) and HCFCs. Many refrigerants are potent greenhouse gases (R-410A has a GWP of \~2,088 times CO₂). Refrigerant tracking is required for comprehensive [Scope 1 emissions](#scope-1-emissions) reporting.
***
### Telecom
**Telecom and related communications services** tracked as a utility commodity — for example phone or data circuits billed like other site utilities. Units and charge structures vary by provider.
***
### Miscellaneous
**Other utility or facility charges** that do not fit Electricity, Natural gas, Water, Sewer, Waste, Fuel, Solar, District, Refrigerant, or Telecom. Use this when the provider bills a site for a commodity outside those categories.
***
### Unit of measure (UOM)
The **unit used to express utility consumption**. Common units in Nectar:
| Commodity | Common units |
| ------------- | ----------------------------------------------------------------- |
| Electricity | kWh, MWh, GWh |
| Natural gas | thm (US), thm (EC), Dth (US), CCF, MCF, MMBtu |
| Water | gal (US), gal (UK), kgal (US), L, kL, CCF, HCF, cubic ft, cubic m |
| Fuel | gal (US), gal (UK), L, bbl |
| Waste | tons (US), metric ton, tonne, kg, lb |
| Solar | kWh, MWh |
| District | MMBtu, GJ, MJ |
| Telecom | Varies by provider |
| Miscellaneous | Varies by provider |
When configuring anomaly monitoring for a site, units are organized into four groups: **Energy** (kWh, MWh, GWh, Btu, MMBtu, thm, Dth, GJ, MJ, kJ), **Volume** (gal, kgal, L, kL, cubic ft, cubic m, CCF, HCF, MCF, bbl), **Mass** (kg, lb, tons, metric ton, tonne), and **Power** (kW, MW).
***
### kWh (Kilowatt-hour)
The standard unit for measuring **electricity consumption**. One kWh = the energy consumed by a 1,000-watt device running for one hour. 1 kWh = 3.412 kBtu.
***
### kW (Kilowatt)
The standard unit for measuring **electricity demand** — the instantaneous rate of consumption. 1 kW = 1,000 watts. Demand is measured as the highest 15- or 30-minute average kW during a billing period.
***
### kBtu (Kilo British Thermal Unit)
A unit of energy equal to **1,000 British Thermal Units (BTU)**. Used to normalize and compare energy consumption across different fuel types. 1 kWh = 3.412 kBtu; 1 therm = 100 kBtu.
***
### MMBtu (Million British Thermal Units)
One million BTU, equal to **10 therms** or **1,000 kBtu**. Common in commercial and industrial natural gas billing. 1 MMBtu ≈ 293 kWh of electricity.
***
### Therm
A unit for measuring **natural gas consumption** equal to 100,000 BTU. The most common unit for residential and commercial gas billing in the United States.
***
### CCF
**Hundred cubic feet** — a unit for measuring natural gas or water consumption. 1 CCF of natural gas ≈ 1.02 therms ≈ 748 gallons of water.
***
### MCF
**Thousand cubic feet** of natural gas. 1 MCF = 10 CCF ≈ 10.2 therms.
***
***
## Energy Performance and Benchmarking
***
### Energy Use Intensity (EUI)
**Energy consumed per unit of floor area per year** — the standard metric for comparing buildings of different sizes and benchmarking performance.
* **Site EUI** — on-site energy consumption ÷ gross floor area. Measured in kBtu/sq ft/year (US) or GJ/m²/year (metric).
* **Source EUI** — total raw energy required (including upstream generation and transmission losses) ÷ gross floor area. Used by [ENERGY STAR Portfolio Manager](#energy-star-portfolio-manager).
A **lower EUI** indicates better energy efficiency. The national median EUI varies by building type: offices typically achieve 50–80 kBtu/sq ft/year; warehouses 20–40 kBtu/sq ft/year.
In Nectar’s [EUI & Intensity](/docs/platform/analytics/intensity) dashboard you can also normalize by a [custom variable](#custom-variable) denominator (for example, production volume) instead of floor area.
***
### Custom variable
A **company-defined metric or attribute** attached to sites — for example monthly production volume, headcount, or a fixed region label. Configured in [**Settings > Company > Sites > General**](https://dash.nectarclimate.com/settings/company/sites).
* **Cadence** — **Monthly** (a per-month time series) or **Fixed** (one static value per site)
* **Type** — **Number** (usable as an intensity denominator on [EUI & Intensity](/docs/platform/analytics/intensity)) or **Text** (shown as optional columns and filters on the [Sites](/docs/platform/sites/overview) list)
See [Custom variables](/docs/platform/settings/custom-variables).
**See also:** [Energy Use Intensity (EUI)](#energy-use-intensity-eui), [Site](#site)
***
### Site energy
The **total energy consumed on-site** during a period, measured at the utility meter. Includes energy purchased from the grid (from utility bills) plus on-site renewable generation consumed locally. Does **not** include upstream losses from electricity generation or transmission.
***
### Source energy
The **total raw fuel required to deliver energy to a building**, including losses during generation, transmission, and distribution. Source energy is more comprehensive than site energy because it captures the full upstream impact. [ENERGY STAR Portfolio Manager](#energy-star-portfolio-manager) uses source EUI for benchmarking because it enables fair comparison between buildings with different fuel mixes.
**Example:** Delivering 1 kWh of electricity to a building requires approximately 3 kWh of raw fuel at the power plant (accounting for generation and transmission losses). So 1 kWh of site electricity = \~3 kWh of source energy.
***
### Weather normalized energy
Energy consumption **adjusted to what it would have been under typical climate conditions**, so a hot or cold year does not look like an efficiency change. Nectar fits each fuel’s monthly energy against outdoor temperature (the ENERGY STAR / E-Tracker approach), then scales actual use by the ratio of energy expected in a normal year to energy expected in that month’s weather.
This is **not** the weather model used for anomaly detection (expected range / residual band), and it is **not** an ENERGY STAR 1–100 score. Combined electricity and gas is the sum of per-fuel weather-normalized energy.
**Why it matters:** Without weather normalization, a cold winter makes energy use look high and a mild winter makes it look low — masking the underlying trend. Weather normalized energy enables fair year-over-year comparisons and energy-per-production-unit tracking.
***
### Degree days
A measure of **how much heating or cooling was needed** during a period, based on outdoor temperature deviation from a base of 65°F (18°C).
* **Heating Degree Days (HDD):** Each day counts as the number of degrees the average temperature was *below* 65°F. More HDD = colder period = more heating needed.
* **Cooling Degree Days (CDD):** Each day counts as the number of degrees the average temperature was *above* 65°F. More CDD = hotter period = more cooling needed.
**Example:** A day with an average temperature of 40°F contributes 25 HDD (65 − 40 = 25). A day at 85°F contributes 20 CDD (85 − 65 = 20).
***
### Baseline
A **reference time period** used for energy comparisons. When benchmarking improvements, the baseline is the earlier period against which the current period is measured. A meaningful baseline might be the 12 months before a retrofit, the prior calendar year, or a specific year required by a reporting framework. In anomaly detection, Nectar builds a weather-adjusted expected range from a site's recent history and flags periods that fall outside it.
**See also:** [Anomaly](#anomaly)
**Docs:** [Anomalies — How detection works](/docs/platform/data-quality/anomalies#how-detection-works)
***
### Benchmark
**Comparing a building's energy performance against a reference standard** — typically a peer group, a historical baseline, or a certification threshold. Nectar provides the structured consumption data that benchmarking platforms use.
***
### ENERGY STAR Portfolio Manager
The **U.S. EPA's free online platform** for benchmarking commercial building energy and water performance. Buildings scoring 75 or higher on ENERGY STAR's 1–100 scale may qualify for certification. Nectar can export structured consumption data directly to ENERGY STAR Portfolio Manager.
**Related docs:** [ENERGY STAR integration](/docs/platform/data-export/integrations/energy-star)
***
### ENERGY STAR score
A **1–100 rating** that measures how well a building performs compared to similar buildings nationwide, normalized for climate, size, and occupancy. A score of 50 = national median performance. A score of 75+ = eligible for ENERGY STAR certification (performs better than 75% of peers).
***
### National median EUI
The **median EUI for a given building type** across the nation, derived from surveys like the U.S. EIA's Commercial Buildings Energy Consumption Survey (CBECS). Buildings with an EUI below the national median use less energy per square foot than at least half of similar buildings.
***
### Net metering
An electricity billing arrangement where **on-site solar generation offsets consumption** from the grid. The utility credits excess generation against consumption on the monthly bill. Net-metered bills show both gross consumption and a generation credit.
***
### Peak demand
The **highest rate of electricity consumption** during a billing period, measured in kilowatts (kW). Typically the highest 15- or 30-minute average during the period. Utilities use peak demand to calculate [demand charges](#electricity-demand-charges).
***
### Bulk import
A flow for creating multiple sites or connection invitations at once from a CSV or Excel file. The platform parses your file in your browser, lets you match columns to platform fields, and shows validation errors inline so you can fix them without re-uploading.
**Phases:**
* **Upload** — drop your file or click **Download template** to start from a blank one.
* **Map columns** — match each platform field to a column in your file. Most columns auto-match by name.
* **Review and fix** — edit cells with validation errors directly in the grid, skip rows you don't want to import, then commit.
**See also:** [Site](#site), [Connection](#connection), [Invitation](#invitation)
**Docs:** [Sites — Bulk import](/docs/platform/sites/overview#bulk-import-sites), [Connections — Bulk invite to connect](/docs/platform/data-input/connections#bulk-invite-to-connect)
***
### Billing demand
The **demand value used by the utility** to calculate the demand charge on a bill. May equal the highest measured [peak demand](#peak-demand) or be adjusted by a ratchet clause that considers demand from prior months (e.g., "billed demand = max of current month's peak or 80% of the highest peak from the past 12 months").
***
### Time-of-use (TOU)
An electricity pricing structure where **rates vary by time of day and season**, reflecting the actual cost of producing electricity. Common TOU tiers: on-peak (highest), partial-peak, off-peak (lowest).
***
### On-peak
The **hours when electricity prices are highest** — typically weekday afternoons and evenings when system-wide demand is greatest (e.g., 4–9 PM weekdays).
***
### Off-peak
The **hours when electricity prices are lowest** — typically nights, early mornings, and weekends.
***
### TOU breakdown
A **section of a bill showing electricity usage split by TOU pricing tiers** — on-peak kWh, partial-peak kWh, and off-peak kWh, along with the corresponding charges for each tier. Nectar extracts TOU breakdowns from bills.
***
### Rate schedule
The **specific pricing plan** under which a utility account is billed. Also called a **tariff** or **rate class**. Commercial accounts often have multiple rate schedules available. Common types: flat rate, time-of-use rate, demand rate, tiered/block rate.
***
***
## Carbon and Emissions Reporting
***
### Greenhouse gas (GHG) emissions
**Carbon dioxide (CO₂), methane (CH₄), nitrous oxide (N₂O), and other gases** released into the atmosphere that trap heat. GHG emissions from utility consumption are quantified in [CO₂e](#co2e) and classified by [scope](#scope-1-emissions).
***
### CO₂e (Carbon dioxide equivalent)
A **standardized unit** for expressing greenhouse gas emissions. Different gases have different warming potentials — methane is \~25× more potent than CO₂ over 100 years. CO₂e converts all gases to their equivalent CO₂ warming effect, enabling comparison. Typically expressed in metric tons tCO₂e or kg CO₂e.
***
### Scope 1 emissions
**Direct GHG emissions from sources owned or controlled** by your organization. Examples: natural gas burned in on-site boilers, diesel burned in company vehicles, refrigerant leaks from on-site HVAC. Natural gas and fuel consumption data from Nectar is the primary input for Scope 1 calculations.
***
### Scope 2 emissions
**Indirect GHG emissions from purchased electricity, heat, steam, or cooling**. These emissions occur at the power plant or generation facility, not at your building, but result from your energy purchases. Two accounting methods:
* **Location-based:** Uses average regional grid emission factors (e.g., [eGRID](#egrid))
* **Market-based:** Uses contract-specific factors or zero-emissions factors when RECs are purchased
Electricity consumption data from Nectar is the primary input for Scope 2 calculations.
***
### Scope 3 emissions
**Indirect GHG emissions from activities not directly owned or controlled** by your organization — including employee commuting, business travel, supply chain, and waste disposal. Scope 3 is typically the largest category of emissions.
***
### Emission factor
A **coefficient converting energy consumption to GHG emissions**. For example, the US average grid electricity emission factor is approximately 0.386 kg CO₂e per kWh (2022). Emission factors vary by fuel type, country, grid region, and year.
***
### eGRID
The **EPA's Emissions & Generation Resource Integrated Database** — provides regional electricity emission factors for grid electricity in the US, used to calculate Scope 2 emissions from electricity consumption.
***
### ESG reporting
**Environmental, Social, and Governance reporting** — disclosure of a company's performance in these three areas to investors, regulators, and the public. Utility consumption and carbon accounting data from Nectar is a core input for the environmental component of ESG reports.
***
### Renewable Energy Certificate (REC)
A **tradable instrument** representing the environmental benefits of 1 MWh of electricity generated from a renewable source. You must own the REC to claim the electricity as [green power](#green-power) in emissions reporting. RECs can be sold separately from the underlying electricity.
***
### Green power
**Electricity from renewable sources** (solar, wind, hydro, geothermal, biomass) where the environmental benefits (RECs) are owned by the purchaser. Purchasing green power can reduce Scope 2 emissions under market-based accounting.
***
### Avoided emissions
The **emissions reduction credited to on-site or purchased renewable energy**. On-site solar panels "avoid" the grid electricity — and its emissions — that would otherwise have been used. Calculated as renewable energy generation × grid emission factor.
***
***
## Data Processing and Methodology
Terms related to how Nectar processes, transforms, and aggregates utility data. For detailed explanations, see the [Methodology](/docs/platform/methodology/overview) section.
***
### Calendarization
The process of **transforming billing period data into calendar month data**. Because billing periods rarely align with calendar months (a bill dated January 20 might cover December 21 – January 20), calendarization prorates usage across the months a billing period touches.
**Algorithm:** Usage is spread evenly across the billing period, then attributed to each calendar month based on the number of overlapping days.
**Example:** A bill with 3,100 kWh covering January 15 – February 14 (31 days) would attribute 1,700 kWh to January (17 days) and 1,400 kWh to February (14 days).
**See also:** [Billing period](#billing-period)
**Docs:** [Calendarization methodology](/docs/platform/methodology/calendarization)
***
### Proration
**Dividing a bill's usage or cost proportionally** based on the number of days that fall within a specific time period. Proration is the underlying mechanism for [calendarization](#calendarization).
**Formula:** `Prorated value = Total value × (Overlap days ÷ Total billing period days)`
**See also:** [Calendarization](#calendarization)
***
### Cost attribution
The process of assigning a bill's net current charges to meters and sites. Nectar preserves line items linked to one site, then allocates the remainder equally across utility types with usage and proportionally within each type. Equal allocation is the fallback only when the bill has no positive usage.
**Example:** A $1,000 electricity charge covering two meters with 60%/40% usage split would attribute $600 and \$400 respectively.
Every usage row on the bill shares in the split, including rows on untracked meters and rows on bills with an open issue — so each meter's figure reflects its own service. Whether that figure is then counted in a portfolio, site, or account total is a separate question: totals still count only tracked meters on bills without open issues.
For a [revised bill](#revised-bill), superseded usage remains part of the earlier bill's historical cost topology even though it leaves usage totals. Revision links do not cancel monetary records; credits and adjustments determine combined spend.
**See also:** [Line items](#line-item), [Net current charges](#net-current-charges), [Superseded usage](#superseded-usage), [Tracked](#tracked)
**Docs:** [Cost attribution methodology](/docs/platform/methodology/cost-attribution)
***
### Cost tracking
Company-level setting (**Settings** > **Company** > **Data Collection**) that controls whether dollar amounts, line items, and cost analytics appear in the platform. When disabled, Nectar emphasizes usage and emissions data while preserving any cost values already stored.
**See also:** [Line items](#line-item), [Cost attribution](#cost-attribution)
**Docs:** [Data collection settings — Cost tracking](/docs/platform/settings/data-collection#cost-tracking)
***
### Implied metering
**Deriving sewer (wastewater) usage from water consumption** when the utility doesn't report sewer volumes directly. Many utilities charge for sewer based on water usage but don't report separate sewer consumption figures.
**Formula:** `Implied sewer = Water usage × Implied metering fraction`
The fraction (default 100%) accounts for water that doesn't become wastewater (e.g., irrigation).
**See also:** [Water](#water)
**Docs:** [Implied metering](/docs/platform/methodology/edge-cases#implied-metering)
***
### Network usage
For time-of-use (TOU) electricity bills, the **sum of on-peak, off-peak, and shoulder usage**. When TOU breakdown is available, network usage is preferred over a single net usage value for analytics.
**Formula:** `Network usage = On-peak + Off-peak + Shoulder`
**See also:** [Time-of-use (TOU)](#time-of-use-tou), [On-peak](#on-peak), [Off-peak](#off-peak)
***
### Active account
When multiple utility accounts cover the same service point (due to account consolidation or restructuring), the **active account** is the primary account used for analytics. Sub-accounts are linked to the active account, and their data flows through it to prevent double-counting.
**See also:** [Account](#account), [Account status](#account-status)
**Docs:** [Account organization](/docs/developer-guide/data-model/meter-organization#account-organization)
***
### Data collection stop date
The date when a site was **archived or soft-deleted**. When set, meters at that site are excluded from active analytics, and bills dated after the stop date are not included in reporting. Historical data before the stop date is preserved.
**See also:** [Site](#site)
***
***
## Data Quality and Validation
***
### Anomaly
A **detected irregularity** in a bill or usage pattern — for example, a spike in consumption, a bill dramatically higher or lower than the historical average, or a gap in expected billing dates. Nectar flags anomalies automatically.
**See also:** [Baseline](#baseline), [Data quality issue](#data-quality-issue)
**Docs:** [Issues triage](/docs/platform/data-quality/issues)
***
### Flagged bill
A bill **marked for review** due to a suspected issue. See [flagged bill](#flagged-bill) and [data quality issue](#data-quality-issue) in the Bills section above for full details.
***
### Completeness
A **data quality metric** expressing how much of the expected utility data has been collected for a given period. On **By Site**, completeness counts months as **Actual** (collected data meets the threshold) or **Estimated** (threshold met only with persisted [usage estimation](/docs/platform/data-quality/usage-estimation) fills). **Future** months are excluded from the denominator. Portfolio **Coverage** percentage is the share of required months that are Actual or Estimated in combined mode.
For most commodities (electricity, gas, water), day-level coverage uses **actual-first** classification: collected usage always wins the day, even when a fill spans the same dates. For **spot-delivery** commodities (fuel and waste), a month is **Actual** when at least one delivery exists.
The completeness page shows a **coverage timeline** — a visual grid where rows represent entities and columns represent billing periods. **By Account** and **By Meter** reflect collected data only.
**Severity tiers:**
* **Critical** — 0–50% coverage
* **Low** — 50–75% coverage
* **Fair** — 75–95% coverage
* **Good** — 95–100% coverage
**See also:** [Coverage basis](#coverage-basis), [Estimated data](#estimated-data), [Missing data](#missing-data), [Data quality](#data-quality)
**Docs:** [Data completeness](/docs/platform/data-quality/completeness), [Usage estimation](/docs/platform/data-quality/usage-estimation), [Filling data gaps](/docs/platform/data-quality/filling-data-gaps)
***
### Coverage basis
A **Completeness By Site filter** that controls whether months covered only by persisted estimation fills count toward coverage. **Actual + estimated** (default) includes blue **Estimated** cells in the portfolio score. **Actual only** shows those same months as **Missing** so the timeline reflects collected source data only.
Coverage basis is a reporting lens — it does not delete fills or change estimation rules. It is separate from [Usage basis](#usage-basis), which controls analytics totals.
**See also:** [Completeness](#completeness), [Estimated data](#estimated-data), [Usage basis](#usage-basis)
**Docs:** [Data completeness](/docs/platform/data-quality/completeness), [Usage estimation](/docs/platform/data-quality/usage-estimation)
***
### Coverage gap
A **month or billing period where expected data was not collected** for a specific entity (site-utility pair, account, or meter). Gaps are shown as red cells (✕) in the [completeness](#completeness) timeline. Clicking a gap cell opens a detail sheet where you can inspect contributing bills, view meter-level breakdowns, see historical usage patterns, and take resolution actions (upload a bill, enter data manually, or navigate to Data Inventory).
**See also:** [Completeness](#completeness), [Missing data](#missing-data)
**Docs:** [Data completeness](/docs/platform/data-quality/completeness), [Filling data gaps](/docs/platform/data-quality/filling-data-gaps)
***
### Missing data
**Gaps in bill or usage history** where expected data was not collected — for example, a month with no bill for a meter that normally bills monthly. Missing data reduces an entity's [completeness](#completeness) score and shows as a red cell in the coverage timeline.
**Common causes:** Connection errors, utility portal outages, new meters not yet discovered, billing schedule changes.
**See also:** [Completeness](#completeness), [Coverage gap](#coverage-gap)
**Docs:** [Data completeness](/docs/platform/data-quality/completeness)
***
### Estimated data
**Persisted site-level usage fills** from Nectar's optional [usage estimation](/docs/platform/data-quality/usage-estimation) module — not utility-estimated readings on a bill and not manually entered usage rows in Data Inventory.
Estimated fills help **By Site** completeness reach threshold and can add to eligible analytics totals when **Actual and estimated** [Usage basis](#usage-basis) is selected. They appear in completeness **Estimation details** and analytics provenance footers, never as meters or bills in the Aggregation Inspector.
**See also:** [Utility-estimated reading](#utility-estimated-reading), [Completeness](#completeness), [Coverage basis](#coverage-basis), [Usage basis](#usage-basis)
**Docs:** [Usage estimation](/docs/platform/data-quality/usage-estimation), [Data completeness](/docs/platform/data-quality/completeness)
***
### Utility-estimated reading
A **usage value printed on a utility bill** as an estimate or read type (for example, when the provider did not obtain an actual meter read). Nectar stores these as collected source data when extracted from the bill.
Do not confuse utility-estimated readings with [Estimated data](#estimated-data) from Nectar's usage estimation module, which fills missing site-level gaps when no bill covers the period.
**See also:** [Estimated data](#estimated-data), [Usage data](#usage-data), [Bill](/docs/platform/glossary#bill)
**Docs:** [Usage data](/docs/platform/data-inventory/usage-data#estimated-usage-data), [Usage estimation](/docs/platform/data-quality/usage-estimation)
***
### Usage basis
An **analytics filter** on eligible site-level usage views (for example [**Analytics > Consumption**](/docs/platform/analytics/consumption)). **Actual and estimated** includes persisted [Estimated data](#estimated-data) in totals, tooltips, and exports. **Actual only** uses collected source usage only.
Usage basis does not change completeness cell statuses. Use [Coverage basis](#coverage-basis) for that. Sub-site filters disable Usage basis because estimation applies to whole-site commodity scope only.
**See also:** [Estimated data](#estimated-data), [Coverage basis](#coverage-basis), [Completeness](#completeness)
**Docs:** [Consumption analytics](/docs/platform/analytics/consumption), [Usage estimation](/docs/platform/data-quality/usage-estimation)
***
### Not required
A billing period explicitly marked as **not expected** — for example, a site that was closed for renovation or a seasonal meter that only operates part of the year. Not-required periods do not count against an entity's [completeness](#completeness) score.
**See also:** [Completeness](#completeness), [Missing data](#missing-data)
**Docs:** [Data completeness](/docs/platform/data-quality/completeness)
***
### Data quality
The platform section for reviewing [anomalies](#anomaly), [flagged bills](#flagged-bill), [missing data](#missing-data), [completeness](#completeness) gaps, and savings opportunities. Data Quality is organized into three tools: **Completeness** for coverage across your portfolio, **Issues** for connection, bill, and meter problems (including anomalies), and **Savings** for estimated cost-saving opportunities.
**Docs:** [Data quality overview](/docs/platform/data-quality), [Issues](/docs/platform/data-quality/issues), [Savings](/docs/platform/data-quality/savings)
***
***
## Data Export and Integrations
***
### Quick export
A one-time xlsx or csv export of usage or cost data, filtered by date range, sites, utility types, and other criteria. Usage exports omit superseded usage; cost exports retain original and correcting bill monetary records.
**See also:** [Superseded usage](#superseded-usage), [Cost attribution](#cost-attribution)
**Docs:** [Quick export](/docs/platform/data-export/quick-export)
***
### Integration export
**Sending utility data directly to a third-party platform** — ENERGY STAR Portfolio Manager, Watershed, Metrio, Sinai, Sphera, or Unravel — in the format required by that platform.
***
### Export history
A **log of all previously completed exports**, including the export type, date, status, and download link.
***
### Metrio
A **sustainability data management platform** (Nasdaq Metrio). Nectar pushes aggregated monthly utility usage to Metrio datasources via API and stores each import report so you can verify what Metrio accepted against your data today.
**Docs:** [Metrio integration](/docs/platform/data-export/integrations/metrio)
***
### Watershed
A **carbon accounting and ESG reporting platform**. Nectar can export consumption data to Watershed.
**Docs:** [Watershed integration](/docs/platform/data-export/integrations/watershed)
***
### Sinai Technologies
An **ESG data management platform**. Nectar can export to Sinai.
**Docs:** [Sinai integration](/docs/platform/data-export/integrations/sinai)
***
### Sphera
An **ESG management platform**. Nectar can export to Sphera.
**Docs:** [Sphera integration](/docs/platform/data-export/integrations/sphera)
***
### Unravel
A **sustainability analytics platform**. Nectar can export to Unravel.
**Docs:** [Unravel integration](/docs/platform/data-export/integrations/unravel)
***
***
## Platform and API
***
### API key
A **secret credential** used to authenticate requests to the Nectar API. Generated in Settings → API Keys. Must be included as a Bearer token in the `Authorization` header of every API request. Keys are shown only once at creation — store them immediately.
**Docs:** [API getting started](/docs/developer-guide/getting-started)
***
### Webhook
An **HTTP callback** that Nectar sends to a URL you configure when specific events occur — for example, when a bill is processed, a connection changes status, or a document upload job finishes. Webhooks enable real-time integration with your own systems. Subscribe to `job.completed.v2` when you need to know an upload finished even if no new document was created.
**Docs:** [Webhooks](/docs/developer-guide/webhooks), [Document upload](/docs/developer-guide/document-upload)
**See also:** [Upload](#upload), [Document](#document)
***
### Sandbox
A **test environment** with sample data for exploring the platform and testing API integrations without affecting live production data.
**Docs:** [Sandbox testing](/docs/developer-guide/sandbox-testing)
***
### Upload
**Manually providing a bill PDF, image, or CSV** to Nectar for automated processing. Nectar's AI processes uploaded documents the same way it processes documents collected via connections. From the upload job detail page you can preview the as-uploaded file and [reprocess](#reprocess) a document with feedback when extraction needs another pass. The API returns a job ID you can [poll](/docs/developer-guide/document-upload) or replace with the `job.completed.v2` [webhook](/docs/developer-guide/webhooks).
**Docs:** [Uploads](/docs/platform/data-input/uploads), [Upload job details](/docs/platform/data-input/upload-detail), [Document upload (API)](/docs/developer-guide/document-upload)
**See also:** [Reprocess](#reprocess), [Bill](#bill), [Document](#document), [Webhook](#webhook)
***
### Reprocess
**Running an uploaded document through processing again** with written feedback that guides extraction. Started from [Data Input > Uploads](https://dash.nectarclimate.com/data-input/uploads) on a document's **Reprocess with feedback** action. Nectar creates a new upload job, marks the source document as reprocessed, and replaces any bill created from that file with the new result.
**Docs:** [Upload job details — Reprocess with feedback](/docs/platform/data-input/upload-detail#reprocess-with-feedback), [Data Input FAQ](/docs/platform/data-input/faq)
**See also:** [Upload](#upload), [Bill](#bill)
***
### Manual entry
**Directly typing bill data** (dates, charges, usage amounts) into Nectar without uploading a file. Available at Data Input → Manual Entry.
***
### Document
See [Document](#document) in the Bills section above.
***
### White label
A **premium feature** allowing organizations to apply custom branding — logo, colors, domain — to the Nectar platform.
**Docs:** [White label](/docs/platform/premium/white-label)
***
### Widget
An **individual chart or data visualization** — for example, monthly electricity consumption, cost breakdown by site, or consumption trends. Widgets appear in the built-in Analytics section and are also the building blocks of a [custom dashboard](#custom-dashboard), where each widget carries its own measure, filters, and time window.
**See also:** [Custom dashboard](#custom-dashboard)
***
### Custom dashboard
A **dashboard you design yourself** under Analytics → Dashboards, assembling [widgets](#widget) (trends, bar charts, metrics, and top lists) onto a grid. Each widget has its own measure, filters, and time window, so one dashboard can compare different sites, commodities, or periods side by side. You can keep a dashboard private, share it with your company (read-only for everyone but the creator), or publish a read-only public link.
**Docs:** [Custom dashboards](/docs/platform/analytics/custom-dashboards)
**See also:** [Widget](#widget), [Data quality](#data-quality)
***
### SOC 2
A **security compliance standard** for service organizations. Nectar holds SOC 2 Type 1 and Type 2 certifications. All utility credentials are encrypted at rest.
***
### Pagination
**Dividing large data sets into pages** to improve performance and readability. Tables in Nectar use pagination — you can navigate between pages and change the number of rows shown per page.
***
**Can't find a term?** Email [support@nectarclimate.com](mailto:support@nectarclimate.com) and
we'll add it to the glossary.