HomeGuidesAPI ReferenceChangelog
Log In
Guides

Turn Bills into kWh

Learn how to estimate energy usage from electricity bills using Arcadia's Bill Solve feature in the On-Demand Cost Calculator API.

Overview

A common challenge that energy companies encounter when analyzing potential projects is determining how much electricity a home or business consumes without access to meter data or reliable usage numbers. Most customers don't know their electricity consumption. While they may have some idea of what they pay for electricity, they have no understanding of how that translates into kWh.

The Arcadia API provides the perfect solution: the Bill Solve option in our On-Demand Cost Calculator. This feature allows you to estimate a customer's energy usage for a single billing period using only the total cost of their bill. Similarly, if your customer knows their annual electricity cost, Bill Solve can estimate their annual kWh consumption.

Our On-Demand Cost Calculator supports these Bill Solve calculations.

How Bill Solve Works

Bill Solve estimates kWh usage by working backward from total bill amounts. It applies the correct tariff rates and structures for the specified billing period to determine how much energy consumption (kWh) would be required to generate the given bill total.

While Bill Solve offers both monthly and annual estimation options, we recommend using the monthly option with exact billing dates for maximum precision. The annual option requires assumptions about how a customer's usage is distributed throughout the year, which can introduce additional uncertainty.

What Bill Solve Does Well

Bill Solve is designed to work best with straightforward electricity tariffs, particularly those with fixed rate structures.

Supports Standard Tiered Tariffs

  • Works effectively when a tariff has clearly defined, fixed kWh tiers (e.g., 0–500 kWh, 501–1000 kWh, etc.)
  • Best suited for cases where energy charges are the primary bill component and don't fluctuate due to demand-based adjustments

Handles Time-of-Use (TOU) Rates

  • Can estimate kWh distribution across fixed TOU windows (e.g., Off-Peak: 10 PM – 6 AM, On-Peak: 2 PM – 7 PM)
  • Ideal when TOU rates are the primary driver of bill variation and demand-based components are minimal

Accounts for Basic Fixed Fees & Simple Demand Charges

  • Handles fixed monthly fees and basic demand charges that don't influence energy tier breakpoints
  • Works best when demand charges follow a fixed structure and don't introduce historical dependencies

When Bill Solve May Not Be a Good Fit

While Bill Solve is an excellent tool for estimating usage under most standard tariff structures, it may not provide accurate results for tariffs with complex, demand-based, or historical pricing rules.

🚫 Tariffs with Demand-Dependent Tiering

  • If the kWh tier structure changes based on a customer's peak demand history, Bill Solve cannot correctly allocate usage across those tiers
  • Example: A tariff where the second tier starts at 80% of the customer's highest demand in the past 12 months—Bill Solve doesn't track historical demand, so it cannot determine the correct tier placement

🚫 Complex Demand Charges That Influence kWh Allocation

  • Some tariffs adjust kWh rates based on measured demand (e.g., higher per-kWh pricing for high-demand customers)
  • Bill Solve assumes a standard energy rate structure and doesn't model demand-based rate shifts

🚫 Ratchet-Based Pricing or Dynamic Tiering

  • If a tariff includes historical peak demand ratchets (e.g., where past demand affects current pricing), Bill Solve doesn't retain past demand values and may misplace consumption into incorrect rate categories

When to Use Bill Solve vs. Alternative Methods

Use Bill Solve if your tariff has clear, fixed kWh tiers and TOU periods, and you need an approximate usage estimate.

⚠️ Consider Alternative Methods if your tariff includes demand-based pricing, historical ratchets, or shifting tier structures.

If you're unsure whether Bill Solve is a good fit for your use case, feel free to reach out to our team for guidance.

Monthly Bill Solve Request

Here's an example of how the monthly option works. For this scenario, we have the following customer:

  1. Residential customer in Southern California Edison territory on the "D" tariff (masterTariffId 447)
  2. Actual bill of $54.71 for the period November 25, 2015, to December 28, 2015

To solve for this customer's monthly consumption value, we'll make the following call to the On-Demand Cost Calculator:

POST /rest/v1/ondemand/calculate
{  
  "fromDateTime": "2015-11-25",  
  "toDateTime": "2015-12-28",  
  "masterTariffId": 447,  
  "billingPeriod": "true",  
  "propertyInputs": [  
    {  
      "fromDateTime": "2015-11-25",  
      "toDateTime": "2015-12-28",  
      "keyName": "total",  
      "dataValue": "54.71",  
      "unit": "cost"  
    },  
    {  
      "fromDateTime": "2015-11-25",  
      "toDateTime": "2015-12-28",  
      "keyName": "baselineType",  
      "dataValue": "typicalElectricity"  
    }  
  ]  
}

Let's break this down. Remember: you can see the full documentation for the On-Demand Cost Calculator here: On-Demand Cost Calculator.

Important Parameters

  1. Prior to this call, we used the customer's ZIP code to determine their current tariff, which in this case is SCE's "D" tariff (masterTariffId 447).
  2. We set our calculation date range with fromDateTime and toDateTime to 2015-11-25 and 2015-12-28, respectively. For the most accurate results, make sure to use the actual dates from the bill.
  3. We set billingPeriod to true because we want to ensure monthly charges (if any) are considered in the calculation.
  4. We have two entries in the propertyInputs array, which are the inputs to our calculation. The first one is the most important: for the billing period, our customer's cost is $54.71, so we send a total property with a dataValue of 54.71. We also need to set the unit to cost so the calculator knows we're referring to dollars instead of kWh or kW.
  5. The second input sets our initial guess for monthly consumption. Instead of choosing a specific value, we're telling the API to use our database of typical consumption patterns to set the first guess. This provides two advantages: the typical profile should start closer to the customer's actual usage, resulting in fewer iterations and faster response times. More importantly, it provides fine-grained hourly data for your guess, resulting in more accurate results for TOU customers.

Running the Calculation

Once we have our request configured, we run it. Here are the results:

{  
  "status": "success",  
  "count": 1,  
  "type": "CalculatedCost",  
  "results": [  
    {  
      "masterTariffId": 447,  
      "tariffName": "Domestic",  
      "totalCost": 54.97,  
      "fromDateTime": "2015-11-25T00:00:00-08:00",  
      "toDateTime": "2015-12-28T00:00:00-08:00",  
      "currency": "USD",  
      "summary": {  
        "subTotalCost": 54.97,
        "taxCost": 0,  
        "totalCost": 54.97,  
        "adjustedTotalCost": 55.07,  
        "kWh": 352.25,  
        "kW": 0.72  
      }  
      ...
    }
  ]
}

According to our calculator, this customer's usage should be approximately 352 kWh for December. What happens if we run it in the other direction? We can use the following request to verify:

POST /rest/v1/ondemand/calculate
{  
  "fromDateTime": "2015-11-25",  
  "toDateTime": "2015-12-28",  
  "billingPeriod": "true",  
  "propertyInputs": [  
    {  
      "fromDateTime": "2015-11-25",  
      "toDateTime": "2015-12-28",  
      "keyName": "consumption",  
      "dataValue": "352"  
    }  
  ]  
}

The results are:

{  
  "status": "success",  
  "count": 1,  
  "type": "CalculatedCost",  
  "results": [  
    {  
      "masterTariffId": 447,  
      "tariffName": "Domestic",  
      "totalCost": 54.92,  
      "fromDateTime": "2015-11-25T00:00:00-08:00",  
      "toDateTime": "2015-12-28T00:00:00-08:00",  
      "currency": "USD",  
      "summary": {  
        "subTotalCost": 54.92,  
        "taxCost": 0,  
        "totalCost": 54.92,  
        "adjustedTotalCost": 55.02,  
        "kWh": 352,  
        "kW": 0  
      }  
      ...
    }
  ]
}

That's how a monthly Bill Solve request works. But what if you want to determine consumption based on a year's electricity cost?

Annual Bill Solve Request

Here's an example of how to estimate usage if you have an annual cost. For this scenario, we have the following customer:

  1. Residential customer in Baltimore Gas & Electric's territory on the "R" tariff (masterTariffId 674)
  2. Estimated annual cost of $1,700 for the period October 15, 2016, to October 15, 2017

To solve for this customer's annual consumption value, we'll make the following call:

POST /rest/v1/ondemand/calculate
{  
  "fromDateTime": "2016-10-15",  
  "toDateTime": "2017-10-15",  
  "masterTariffId": 674,  
  "billingPeriod": "false",  
  "propertyInputs": [  
    {  
      "fromDateTime": "2016-10-15",  
      "toDateTime": "2017-10-15",  
      "keyName": "total",  
      "dataValue": "1700",  
      "unit": "cost"  
    },  
    {  
      "fromDateTime": "2016-10-15",  
      "toDateTime": "2017-10-15",  
      "keyName": "baselineType",  
      "dataValue": "typicalElectricity"  
    }  
  ]  
}

Important Parameters

  1. For this example, like the previous one, we used the customer's ZIP code to determine their tariff. In this case, the customer is on BGE's "R" tariff (masterTariffId 674).
  2. We set our billing period with fromDateTime and toDateTime to 2016-10-15 and 2017-10-15, respectively. As with monthly Bill Solve, using the day of the month from the bill will improve precision.
  3. We set billingPeriod to false because this calculation spans multiple billing periods, not just one. This is important for tariffs that have fixed monthly charges.
  4. We have two entries in the propertyInputs array, which are the inputs to our calculation. The first one is the most important: for the billing period, our customer's cost is $1,700, so we send a total property with a dataValue of 1700. We also need to set the unit to cost so the calculator knows we're referring to dollars instead of kWh or kW.
  5. The second input sets our initial guess for monthly consumption. Instead of choosing a specific value, we're telling the API to use our database of typical consumption patterns to set the first guess. This provides two advantages: the typical profile should start closer to the customer's actual usage, resulting in fewer iterations and faster response times. More importantly, it provides fine-grained hourly data for your guess, resulting in more accurate results for TOU customers.

Running the Calculation

Once we have our request configured, we run it. Here are the results:

{  
  "status": "success",  
  "count": 1,  
  "type": "CalculatedCost",  
  "results": [  
    {  
      "masterTariffId": 674,  
      "tariffName": "Residential",  
      "totalCost": 1702.21,  
      "fromDateTime": "2016-10-15T00:00:00-04:00",  
      "toDateTime": "2017-10-15T00:00:00-04:00",  
      "currency": "USD",  
      "summary": {  
        "subTotalCost": 1702.21,  
        "taxCost": 0,  
        "totalCost": 1702.21,  
        "adjustedTotalCost": 1702.21,  
        "kWh": 11108.53,  
        "kW": 3.75  
      }  
      ...
    }
  ]
}

According to our calculator, this customer's usage should be approximately 11,109 kWh for the year starting in mid-October 2016. What happens if we run it in the other direction? We can use the following request to verify:

POST /rest/v1/ondemand/calculate
{  
  "fromDateTime": "2016-10-15",  
  "toDateTime": "2017-10-15",  
  "masterTariffId": 674,  
  "billingPeriod": "false",  
  "propertyInputs": [  
    {  
      "fromDateTime": "2016-10-15",  
      "toDateTime": "2017-10-15",  
      "keyName": "consumption",  
      "dataValue": "11109"  
    }  
  ]  
}

The results are:

{  
  "status": "success",  
  "count": 1,  
  "type": "CalculatedCost",  
  "results": [  
    {  
      "masterTariffId": 674,  
      "tariffName": "Residential",  
      "totalCost": 1708.23,  
      "fromDateTime": "2016-10-15T00:00:00-04:00",  
      "toDateTime": "2017-10-15T00:00:00-04:00",  
      "currency": "USD",  
      "summary": {  
        "subTotalCost": 1708.23,  
        "taxCost": 0,  
        "totalCost": 1708.23,  
        "adjustedTotalCost": 1708.23,  
        "kWh": 11109,  
        "kW": 0  
      }  
      ...
    }
  ]
}

That's it! Remember, calculating usage for a single bill will yield more precise results than an annual calculation.