> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nectarclimate.com/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](/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
Anomalies, flags, completeness
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-items), 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](/platform/data-inventory/bills), [Bill detail](/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, a **severity** (error or warning), and **guided resolution steps** that appear as cards on the record's detail page.
Whether a record's data is withheld from analytics 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** does not withhold usage. Examples: low confidence site match, low confidence address, 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?](/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](/platform/data-quality/issues), [Bill detail — Data quality issues](/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 sorting, filtering, and time-series analytics. When you set a date range filter in the platform, it filters on the bill date.
**Why it matters:** The bill date determines where a bill appears in your data timeline. For trend analysis, Nectar 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](#anomaly) 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](/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:** The due date is informational only — Nectar does not automatically trigger any action based on the due date.
***
### 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. Nectar will exclude it from per-meter analysis but retain it 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 detail](/platform/data-inventory/bill-detail#data-quality-issues) page to see the issue resolution cards, or use the [Issues triage inbox](/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 values: **Waiting validation**, **In exception**, **Funding requested**, **Funding received**, **Payment processing**, **Payment failed**, **Paid**, 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](/platform/bill-pay/overview), [Funding overview](/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](/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](/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](/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](/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](/platform/bill-pay/funding)
***
### Revised bill
A bill that has been **corrected or superseded** by a newer version issued by the utility. Revised bills appear with a revision banner in the bill detail view. Nectar links the original and revised versions so you can compare them.
**Why utilities issue revisions:** Meter read errors, estimated reads that were later corrected, rate adjustments.
***
### Raw datasource name
The **utility provider name as it appeared on the original bill** or in the utility portal, before Nectar matched it to a known [datasource](#datasource). Used for matching and deduplication when Nectar has encountered slight variations in a utility's name (e.g., "Pacific Gas & Electric" vs. "PG\&E").
***
***
## 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.)
***
### 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 items
**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:**
* [Primary ID](#primary-id) — the value shown as the main meter label in lists and sheets
* [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](/platform/data-inventory/meters), [Meter detail](/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), [Meter](#meter)
**Docs:** [Meter detail — Managing identifiers](/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](/platform/data-inventory/meters).
**See also:** [Meter](#meter), [Site tag](#site-tag)
**Docs:** [Meters — Row selection and bulk actions](/platform/data-inventory/meters#row-selection-and-bulk-actions)
***
### Primary ID
The **single identifier value** Nectar displays in tables, headers, and detail views to label a meter. Because a meter can have many [identifiers](#meter-identifier) of different types, Nectar resolves which one 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 matters:** The Primary ID lets you control how meters are labeled across the platform without changing the underlying data. Set the account's primary identifier type in the [account detail](/platform/data-inventory/account-detail) to choose which identifier appears for all meters under that account.
**See also:** [Meter identifier](#meter-identifier), [Account](#account)
**Docs:** [Meter detail — How the Primary ID is determined](/platform/data-inventory/meter-detail#how-the-primary-id-is-determined)
**See also:** [Primary ID](#primary-id) — how the main label is chosen when a meter has several identifiers.
***
### Primary ID
The **main label Nectar shows for a meter** in tables, sheets, and other summaries — for example, the **Meter identifier** column on **Data Inventory > Meters**. It is not stored as its own field; it is **selected** from the identifier values on that meter using your configuration and consistent fallback rules.
**How it is chosen:** On each [account](#account), you can set a **primary** and **secondary** identifier *type* (the kinds of reference numbers your utility uses — see [Account detail](/platform/data-inventory/account-detail)). When those types have values on the meter, Nectar prefers them for the label. Otherwise, Nectar uses a **standard order** among common utility reference numbers until it finds one to display. If nothing is available, the label may be empty and the interface may show a contextual placeholder.
**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.
**See also:** [Meter](#meter), [Meter identifier](#meter-identifier), [Account](#account), [Account number](#account-number)
**Docs:** [Meter detail](/platform/data-inventory/meter-detail), [Account detail](/platform/data-inventory/account-detail), [Meters overview](/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.
***
### 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:**
* [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.
**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](/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](/platform/data-input/connections), [Connection statuses (API)](/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](/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](/platform/data-input/invitations) for the end-user experience and [Connection invitations](/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 score](#completeness) 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 eight 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 or reclaimed water | Gallons, CCF, cubic meters |
| **Waste** | Disposal and diversion services | Pounds, tons |
| **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 |
***
### 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, measured in **gallons** (US) or **CCF** (hundred cubic feet). 1 CCF ≈ 748 gallons. Nectar tracks both potable (drinking-quality) and reclaimed (recycled) water.
***
### Waste
Waste **disposal and diversion services**, measured in pounds or tons. Nectar tracks waste management categories such as landfill disposal, recycling, composting, and donation/reuse. The [waste diversion rate](#waste-diversion) is a key sustainability metric.
**See also:** [Waste type](#waste-type), [Waste stream](#waste-stream), [Waste mapping rule](#waste-mapping-rule), [Waste diversion](#waste-diversion)
**Docs:** [Waste tracking](/platform/methodology/waste-tracking)
***
### Waste type
The **material category** of a waste record — for example, cardboard, organics, or mixed solid waste. Each waste type carries a **density** used to convert volume-based pickups into a common mass unit. A waste type is connected to a processing method by a [waste mapping rule](#waste-mapping-rule).
**See also:** [Waste](#waste), [Waste stream](#waste-stream), [Waste mapping rule](#waste-mapping-rule)
**Docs:** [Waste tracking](/platform/methodology/waste-tracking)
***
### Waste stream
The **processing method or end destination** of a waste record — for example, landfill, recycled, composted, or donated. Waste streams determine the [waste diversion rate](#waste-diversion). A [waste type](#waste-type) is assigned to a stream by a [waste mapping rule](#waste-mapping-rule).
**See also:** [Waste](#waste), [Waste type](#waste-type), [Waste mapping rule](#waste-mapping-rule), [Waste diversion](#waste-diversion)
**Docs:** [Waste tracking](/platform/methodology/waste-tracking)
***
### Waste mapping rule
A rule that connects a [waste type](#waste-type) to a [waste stream](#waste-stream). Mapping rules can be scoped company-wide, to a single hauler, or to a single site, and the most specific match wins — so the same material can route to different streams depending on where it was generated.
**See also:** [Waste type](#waste-type), [Waste stream](#waste-stream), [Waste](#waste)
**Docs:** [Waste tracking](/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.
***
### 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 |
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.
***
### 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 reflect what it would have been under average weather conditions**, removing the effect of unusually hot or cold weather. Uses [degree days](#degree-days) and a regression model of how the building's energy use responds to temperature.
**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 efficiency trend. Weather normalized energy enables fair year-over-year comparisons.
***
### 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](/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](/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](/platform/sites/overview#bulk-import-sites), [Connections — Bulk invite to connect](/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.
***
### Waste diversion
The **amount of waste redirected from landfill** through recycling, composting, donation, or reuse. The **waste diversion rate** (diverted waste ÷ total waste) is a key sustainability metric. Higher diversion reduces methane emissions from landfill decomposition.
***
***
## Data Processing and Methodology
Terms related to how Nectar processes, transforms, and aggregates utility data. For detailed explanations, see the [Methodology](/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](/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 **allocating charges to specific meters** when a bill covers multiple meters or service points. Nectar uses proportional allocation (by usage) for charges of the same commodity type, and equal allocation for account-level charges.
**Example:** A $1,000 electricity charge covering two meters with 60%/40% usage split would attribute $600 and \$400 respectively.
**See also:** [Line items](#line-items)
**Docs:** [Cost attribution methodology](/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-items), [Cost attribution](#cost-attribution)
**Docs:** [Data collection settings — Cost tracking](/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](/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](/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:** [Anomalies](/platform/data-quality/anomalies)
***
### 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. Completeness is calculated as the ratio of complete months to total required months (excluding future periods), expressed as a percentage. It can be viewed at the site-utility, account, or meter level.
For most commodities (electricity, gas, water), a month is complete when it has sufficient day-level coverage. For **spot-delivery** commodities (fuel and waste), a month is complete as long as at least one delivery record exists — reflecting the fact that these commodities are delivered on individual days rather than consumed continuously.
The completeness page shows a **coverage timeline** — a visual grid where rows represent entities and columns represent billing periods. Each cell is marked as complete (✓), missing (✕), or future (·). Click any cell to open a detail sheet with contributing bills, meter breakdowns, usage history, and resolution actions.
**Severity tiers:**
* **Critical** — 0–50% coverage
* **Low** — 50–75% coverage
* **Fair** — 75–95% coverage
* **Good** — 95–100% coverage
**Example:** A site with 80% completeness means 20% of expected billing periods are missing data for the selected reporting period.
**See also:** [Missing data](#missing-data), [Data quality](#data-quality)
**Docs:** [Data completeness](/platform/data-quality/completeness)
***
### 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](/platform/data-quality/completeness)
***
### 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](/platform/data-quality/completeness)
***
### Estimated data
A billing period where **Nectar has generated an estimate** in place of an actual bill. Estimated values are derived from historical usage patterns and clearly marked so they are not confused with verified data.
**See also:** [Completeness](#completeness), [Missing data](#missing-data)
**Docs:** [Data completeness](/platform/data-quality/completeness)
***
### 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](/platform/data-quality/completeness)
***
### Data quality
The platform section for reviewing [anomalies](#anomaly), [flagged bills](#flagged-bill), [missing data](#missing-data), and [completeness](#completeness) gaps. Data Quality is organized into three tools: the **Issues** dashboard for tracking connection, bill, and meter problems, the **Completeness** page for visualizing coverage gaps across your portfolio, and the **Anomalies** page for detecting cost spikes, usage spikes, late fees, and demand charge anomalies.
**Docs:** [Data quality overview](/platform/data-quality)
***
***
## Data Export and Integrations
***
### Quick export
A **one-time CSV export** of usage or cost data, filtered by date range, sites, commodities, and other criteria. Available at 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](/platform/data-export/integrations/metrio)
***
### Watershed
A **carbon accounting and ESG reporting platform**. Nectar can export consumption data to Watershed.
**Docs:** [Watershed integration](/platform/data-export/integrations/watershed)
***
### Sinai Technologies
An **ESG data management platform**. Nectar can export to Sinai.
**Docs:** [Sinai integration](/platform/data-export/integrations/sinai)
***
### Sphera
An **ESG management platform**. Nectar can export to Sphera.
**Docs:** [Sphera integration](/platform/data-export/integrations/sphera)
***
### Unravel
A **sustainability analytics platform**. Nectar can export to Unravel.
**Docs:** [Unravel integration](/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](/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 or a connection changes status. Webhooks enable real-time integration with your own systems.
**Docs:** [Webhooks](/developer-guide/webhooks)
***
### Sandbox
A **test environment** with sample data for exploring the platform and testing API integrations without affecting live production data.
**Docs:** [Sandbox testing](/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.
**Docs:** [Uploads](/platform/data-input/uploads)
***
### 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](/platform/premium/white-label)
***
### Widget
An **individual chart or data visualization** in the Analytics section — for example, monthly electricity consumption, cost breakdown by site, or consumption trends.
***
### 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.