Energy Apps: Recalculate When a User’s Tariff Changes
When an energy tariff changes, an app should preserve the old calculation, apply the new rate from its effective date and make the estimate’s basis clear.
An energy app can produce a plausible cost estimate and still mislead users if it silently applies a new tariff to old usage. The key product question is not simply how to display a rate: it is how to identify which rate applied to each calculation, when to recalculate, and how to explain the result. A Google Trends NL signal points to changing energy pricing structures, with NOS and NU.nl reporting on proposed changes to how households pay for energy use and network charges. That context makes a durable engineering decision timely: how should a mobile app update calculations when a user’s energy tariff changes?
Model tariff changes as dated records, not overwrites
Do not treat a tariff as one mutable number attached to an account. Store each version with its provider or source, applicable tariff components, currency and unit, and an effective-from date; include an effective-to date when known. Keep the date the app received or confirmed the record separately from the date it applies. That distinction lets the system answer two different questions: what rate was believed to apply to a past period, and what information was available to the app at the time? It also gives support teams a traceable basis for investigating a disputed estimate.
Usage must be matched to the tariff valid for its time period. If a billing or usage interval straddles a tariff change, split the interval at the effective date before calculating costs; do not apply the new rate to the whole interval by default. Preserve the usage readings and the tariff version used as calculation inputs. This makes recalculation reproducible and prevents a later tariff update from silently rewriting historical estimates. If the app cannot establish an effective date or a required rate component, label the calculation incomplete or request confirmation rather than implying precision.
- Record effective dates separately from ingestion timestamps.
- Retain the source and version of every tariff used in a calculation.
- Define how intervals crossing a change date are divided.
Make recalculation behaviour explicit to users
When a confirmed tariff change arrives, recalculate affected future estimates using the new version and show the user what changed. A concise explanation might identify the applicable date range, the previous and current assumptions, and whether the displayed figure is a projection or a billed amount. Keep completed historical calculations tied to their original tariff version; offer a clearly labelled revised view only when there is a reason to restate them. This avoids confusing a changed estimate with a change in the user’s past consumption, and gives people a useful way to compare results without erasing the original basis.
A hypothetical example: a household has an estimate for a week that begins before a new rate takes effect and ends after it. The app divides the usage period at the effective date, calculates each part with its applicable tariff, and combines the results. On the estimate screen it can show the tariff version and date range used, plus a notice that the figure is an estimate based on recorded usage. If a user enters a different effective date, the app should identify that the calculation has been updated and retain enough history to explain the earlier result.
- Differentiate estimated, confirmed and billed figures in labels and detail views.
- Explain when recalculation occurs and what data triggered it.
- Keep a visible route to the tariff assumptions behind an estimate.
Scope the data contract and test the edge cases
Before choosing an integration, establish who supplies tariff records, how changes are communicated, and whether the source provides effective dates and all components needed for the app’s intended calculation. A feed that supplies a current headline rate may not be sufficient for a historical or interval-based estimate. Define behaviour for missing, delayed, corrected or conflicting records, and decide whether users can enter or confirm a rate manually. These choices affect backend data design, mobile screens, support processes and QA; they belong in MVP scope rather than being left as a display detail.
A focused first release can support one well-defined tariff type and a transparent estimate workflow before attempting broad provider coverage or complex optimisation. Test a rate change in the future, a late-arriving change, a correction to a previously published record, missing components, overlapping effective periods, and usage that crosses a change date. Also test what a user sees offline or while the app cannot refresh its tariff data: show the last checked time and avoid presenting an old-rate calculation as current. These cases help estimate integration and QA effort without requiring a speculative feature roadmap.
- Ask providers or data partners for sample records and correction rules before committing to an integration.
- Include versioning, historical retention and calculation auditability in backend estimates.
- Test repeated updates for duplicate application and inconsistent results.
A reliable tariff-change workflow depends on dated rate versions, calculations that can be reproduced, and clear communication about what each estimate represents. Preserve the rate used for past calculations, apply new rates only to the periods they govern, and make uncertainty visible when source data is incomplete or late. For product leaders, the practical scoping question is whether the available tariff data supports the dates and components the app promises to calculate. Answering that early helps keep the MVP credible and makes integration, testing and support requirements more predictable.