Reference · built on requestOperator by FibricEnergy & demand

Rate Switch

Twelve months of interval data priced against every eligible rate at your utility, with a switch request proposed when one costs less.

Request accessPricing ↗

About

Most accounts sit on the rate they were opened on. This operator takes twelve months of IntervalBlock readings for each account, from Green Button Connect My Data, UtilityAPI, or your own meters, and prices them under every rate the OpenEI Utility Rate Database lists for your utility and sector. Rates whose peakkwcapacity or peakkwhusage bounds exclude the account are set aside and named.

When a candidate costs less over the year than the rate you are on, it proposes a switch request with both totals side by side. The account owner approves, the request goes to the utility by hand, and the ledger gets a memo.

This is a reference listing. It documents what Fibric would read from Rate Switch and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Twelve months of IntervalBlock readings per UsagePoint through Green Button Connect My Data or UtilityAPI
  • Every rate for your utility and sector in URDB, with startdate, enddate, and the approved flag on each record
  • Eligibility bounds on each rate: peakkwcapacitymin and peakkwcapacitymax, peakkwhusagemin and peakkwhusagemax
  • The rate the account is on now, from the UsageSummary tariff profile or the rate name printed on the bill
  • Monthly peak demand from your own interval meters over Modbus TCP, where the utility feed carries no demand
  • Utility spend by account in NetSuite, Sage Intacct, or QuickBooks Online, so the model is checked against what was paid

Proposed actions

  • Target capability: propose a rate change request for an account, with the twelve-month cost under the current rate and under the candidate
  • Target capability: propose a note listing the rates set aside on eligibility, with the URDB field that excluded each
  • Target capability: propose a re-run when URDB shows a new version of the current rate or a candidate, with its effective date
  • Target capability: propose a task for the account owner to confirm the utility's switching rules and any minimum term
  • Target capability: propose a ledger memo on the utility vendor recording the request date and the first bill expected on the new rate

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • A commercial account with a demand rate

    Twelve months of Green Button intervals are priced under each commercial rate URDB lists for the utility. A rate with a lower demand charge and a higher energy charge comes out cheaper, and the request is drafted.

    With Green Button Connect My Data, OpenEI Utility Rate Database

  • A yearly check across many sites

    Every account under UtilityAPI is re-priced once a year, with the modelled cost reconciled to the spend Sage Intacct recorded for the same months before any request is proposed.

    With UtilityAPI, Sage Intacct

  • Own meters, no utility feed

    Where the utility offers no data feed, your Modbus TCP main meter supplies the intervals and NetSuite the spend. The proposal notes that demand comes from your meter, not the utility's.

    With Modbus TCP, NetSuite

Requirements

  • Twelve months of interval data per account: Green Button Connect My Data, UtilityAPI, or your own Modbus TCP meters
  • Your utility's rates in URDB, filtered by sector, and a free OpenEI API key
  • The account's current rate label, plus any rider or contract that alters the published charges
  • Read access to utility spend in NetSuite, Sage Intacct, or QuickBooks Online for the reconciliation column
Authentication
It never signs in to the utility. Interval data comes through the customer authorization or UtilityAPI, rates from OpenEI with your key, and spend through the ledger role you assign.

Limits

  • Eligibility is checked against the fields URDB holds. Rules kept only in tariff text, such as a minimum term, are yours to confirm.
  • An account with fewer than twelve months of data is priced on what exists and the proposal says so.
  • The utility decides whether and when a switch takes effect. The operator prepares the request; a person files it.
  • Ratchets, riders, and taxes that URDB does not model are left out and listed on the proposal.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Rate Switch ↗

Questions and answers

What does the account owner approve?
One proposal per account: the current rate, the candidate, the twelve-month cost of each from the same interval data, the eligibility checks, and the items URDB could not model. Approval drafts the request; the owner may decline with a reason.
What is recorded for each account it priced?
A receipt per account: the interval window, the URDB records and versions priced, the cost under each, the rates set aside and why, who approved, and the request text as drafted.
Can it ever switch a rate itself?
No. There is no path from this operator to the utility's account system. A person sends the request, once, and the ledger memo follows only after that approval.
Ask about Rate Switch

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy