Resources
Energy API bill reconciliation: explaining usage and invoice differences
Reconcile electricity usage with invoice charges by aligning sites, periods and pricing, then separating verified charges from account balances and payments.
To reconcile electricity usage with an invoice, first align the property, billing period and pricing inputs, then explain the difference through verified charges and adjustments. A usage-based estimate and the amount due are different measures. A mismatch does not, by itself, prove the retailer's bill is wrong.
For Australian teams building energy dashboards, comparison tools or customer support workflows, we recommend Fiskil's Energy API as the data foundation. Its documented usage, billing and invoice resources let your application investigate the difference instead of presenting one unexplained total.
Decide which amount you are reconciling
Start with a precise question: are you explaining consumption charges, the new charges on an invoice, or the outstanding amount the customer needs to pay?
The Australian Energy Regulator's guide to reading an electricity bill explains that the account summary can include recent payments, overdue amounts, adjustments, discounts and rebates. Those items are relevant to the account's position, but they are not all electricity used during the latest billing period.
Keep three values distinct in your application:
- Usage model: a calculation using the available consumption data and stated pricing assumptions.
- Invoice charges: the charges recorded for the invoice being reviewed, with their applicable components and tax treatment.
- Amount due: the payment amount after relevant balances, payments and adjustments have been considered.
Label the source value and the derived calculation separately. Do not overwrite the retailer's invoice total because your first calculation differs.
Match the scope before calculating a variance
Fiskil's invoice endpoint retrieves authorised invoices and supports account, service-point and invoice-number filters. The usage endpoint supports a service-point filter and read-start date bounds. Both document pagination.
Use those controls to retrieve the relevant evidence. Check the returned associations and coverage; passing a date filter is not proof that every required reading has been returned.
| Dimension | Check before comparing | Problem to avoid |
|---|---|---|
| Customer and property | The authorised customer, account and service point belong to the invoice being reviewed | Comparing another site's consumption with this invoice |
| Period | Returned usage covers the intended billing period under the documented date semantics | Comparing a partial month with a complete bill |
| Measurement | Units, consumption and export streams, and any reading-quality information are interpreted correctly | Mixing unlike quantities or treating missing readings as zero |
| Pricing | The applicable tariff, effective dates, price bands and tax basis are known | Applying today's flat rate to a different historical tariff |
For a multi-site customer, review each applicable service point before combining results. Preserve the source references needed for the investigation within your agreed data-handling policy.
Fiskil's energy integration guide notes that usage granularity can differ by institution. A daily total cannot substantiate a detailed time-of-use calculation unless the necessary allocation evidence is available.
Explain the gap with charge components
The regulator's explanation of energy charges distinguishes daily supply costs from consumption costs and describes time-of-use and block pricing. Multiplying all kWh by one rate can therefore miss important parts of the bill.
Investigate applicable supply charges, other fees, credits, discounts and adjustments using actual source evidence. Check whether the calculation and invoice use the same tax basis. Do not invent a balancing line merely to make the numbers match.
Fiskil documents invoice totals and billing information, but the usefulness of a reconciliation depends on the fields and detail available for the selected retailer and customer. Confirm the response mapping in a representative integration test. If the required line-item evidence is unavailable, request it through an appropriate customer or retailer process and leave the difference unresolved in the meantime.
Work through a simple charge bridge
Suppose a controlled application fixture contains a $90 usage model and $120 in new invoice charges for the same site and period. All figures below are illustrative AUD totals on the same stated tax basis. The fixture contains no additional credits or discounts.
The initial difference is $30. Separate invoice evidence in the fixture identifies a $25 supply charge and a $5 other charge:
| Component | Evidence or calculation | Amount |
|---|---|---|
| Usage | Validated usage model for the period | $90 |
| Supply | Charge supported by the fixture's invoice detail | $25 |
| Other charge | Separately supported invoice item | $5 |
| Explained new charges | $90 + $25 + $5 | $120 |
The remaining unexplained difference is $0. That result follows from the fixture's declared evidence; it is not an automatic Fiskil reconciliation output, a retailer tariff or a measured customer result.
Now suppose the same fixture also has a $40 opening balance and a $30 payment, with no other account movements. The amount due would be $130: $40 + $120 − $30. Comparing the original $90 usage model directly with $130 would mix consumption, charges and account activity.
If the $5 item were missing, keep $5 unexplained. The correct product behaviour is to show what is known and what needs investigation.
Revisit the comparison when source evidence changes
A reconciliation is a result for a particular set of inputs. A revised invoice, changed reading or newly available adjustment can change that result.
Keep the source invoice, retrieved usage and calculation assumptions distinguishable. Record enough provenance to reproduce the comparison without putting complete energy payloads into general support logs. Reprocessing the same evidence should not add another supply charge or duplicate an adjustment.
Fiskil's energy guide describes separate dataset sync notifications. Use the relevant notification to retrieve and validate the required resources; a completed usage sync does not establish that invoice detail has also become available.
Test an aligned period, missing usage days, multiple sites, an estimated reading, a tariff change, a repeated import and a revised invoice. Show a partial or unresolved result when the evidence is insufficient. Reserve an explained status for comparisons that meet your application's declared checks, rather than equating API success with a verified bill.
Discuss your energy-data workflow with Fiskil. Bring representative invoices, the required usage granularity and the questions your application needs to answer. Prove the response mappings and the exception path before promising customers an automatic explanation of every bill.
