Usage Event ReRating

Table of Contents

Overview

Last verified with: 10.8.6.0

Overview #

Usage rerating is the process of rating usage again after the context used to rate that usage has changed.

This guide is intended to answer a practical question: when a user, integration, or system process changes billing or usage configuration, what should you expect the system to do with usage that may already have been processed?

In LogiSense Billing, a rerate is usually created when a change can affect existing usage. The rerate does not mean that every usage record is immediately recalculated at the moment of the change. Instead, the system creates a pending rerate request, and a rerate schedule later processes the affected account and usage period.

What Creates A Rerate #

A rerate can be created by:

a manual user or API request,
account package changes,
account service changes,
usage bucket changes,
usage bucket tier changes,
share plan changes,
account price plan date changes,
or package service price plan usage rate overrides.

A rerate schedule can then be started manually, by a scheduled rerate, or by a bill run that finds pending rerates and needs them processed before billing continues.

What this means is:

rerates are driven by changes to the rating context,
the system tries to avoid rerating when the change cannot affect existing usage,
and the rerate start date is normally based on the earliest affected usage or affected usage period, not simply the date the change was made.

The Core Rule Set #

The most important behaviors to understand are:

a rerate request is created only when the change affects usage-rating context,
many automatic rerate triggers first check whether relevant usage exists,
only specific fields are tracked for rerate creation,
some share plan and bucket changes update daily thresholds before the rerate is queued,
billing activation packages that have not yet activated are normally skipped,
and manual rerates are marked as user initiated.

What this means is:

updating an unrelated display field should not create a rerate,
changing a date, bucket amount, unit, contribution, participation limit, or usage rate override can create a rerate,
and the same change can produce a parent-only rerate or a parent-and-children rerate depending on whether child accounts can be affected.

Automatic Trigger Summary #

The automatic rerate reasons you may see are:

Area	Change that can queue a rerate	Rerate reason
Account package	Package is added, removed, or has effective dates changed	`Account Package Added`, `Account Package Removed`, `Account Package Updated`
Account service	Service is added, removed, or has effective dates changed	`Account Service Added`, `Account Service Removed`, `Account Service Updated`
Usage bucket	Bucket is added in a shared or share-plan add-on scenario, or bucket timing/expiration changes	`Account Service Usage Bucket Added`, `Account Service Usage Bucket Updated`
Usage bucket tier	Tier flat charge, threshold, or usage unit changes	`Account Service Usage Bucket Tier Updated`
Share plan	Share plan is added, contribution changes, participation limits change, or product-code participation changes update contribution values	`Account Share Plan Added`, `Account Share Plan Contribution Updated`, `Account Share Plan Participation Updated`
Account price plan	Start or end date changes on an account price plan with overridden rates	`Account Price Plan Dates Updated`
Usage rate override	Package service price plan usage rate override is added, or amount/unit changes	`Account Package Service Price Plan Rate Override Updated`

These reasons describe why the rerate was queued. They do not guarantee that every record in the account will change price; they identify the rating context that needs to be evaluated again.

Manual Rerates #

A user or integration can explicitly request a rerate.

What this means is:

a rerate can be started for a usage invoicer account,
a rerate start date can be supplied,
if an account is supplied without a start date, the system can use the minimum supported date so the account can be rerated from the beginning,
batch rerates can include multiple usage invoicer accounts,
and these rerates are recorded with the reason User Initiated.

Example:

Account: Acme Corp
Account is its own usage invoicer
Rerate start: October 1
Manual rerate requested on November 15

Expected behavior:

the system creates a rerate schedule,
the account is queued for rerating from October 1,
and usage on or after that start date can be processed again.

Account Packages #

Account package changes can create rerates when package timing or share-plan participation affects usage.

What this means is:

creating or deleting an account package can create a rerate if that package contributes to a share plan,
updating an account package effective date or effective cancel date can create a rerate,
share plan packages and share plan add-on packages have specific rerate handling,
services that inherit package dates can also be affected by a package date change,
and billing activation packages that have not yet activated are skipped because their contributions have not yet taken effect.

Example:

A package contains a usage service
Usage has already been processed for October
The package effective cancel date is moved from October 31 to October 15

Expected behavior:

the system checks whether package or service timing now changes the period in which usage should have been rated,
if affected usage exists, a rerate is queued,
and the rerate starts from the earliest affected date.

Account Services #

Account service changes can create rerates when they affect usage-based services, billing activation services, or share plan contributions.

What this means is:

creating or deleting an account service can create a rerate when the service contributes to a share plan,
updating an account service effective date can create a rerate,
updating an account service effective cancel date can create a rerate,
these date-change rerates apply to usage-based and billing activation services,
share plan services are excluded from the service date-change rerate path,
and the system checks whether usage exists in the affected period before creating the rerate.

Example:

A usage-based service was effective October 1
Usage was processed on October 5
The service effective date is changed to October 10

Expected behavior:

the system checks for usage that now falls outside the updated service period,
if affected usage exists, a rerate is queued,
and the affected usage can be recalculated or moved to exception handling depending on the new context.

Usage Buckets #

Usage bucket changes can create rerates when bucket availability, bucket timing, or bucket sharing changes how existing usage should consume allowance.

What this means is:

creating an account service usage bucket can create a rerate for share plan add-on or shared-across-package bucket scenarios,
updating a bucket effective date can create a rerate,
updating a bucket effective cancel date can create a rerate,
updating bucket expiration settings can create a rerate,
the bucket must have relevant usage,
and when the bucket belongs to a share plan, the system also checks whether the bucket is bucketable.

Example:

A shared bucket becomes effective on October 1
Usage from services in the same package has already been processed
A new shared bucket is added after that usage was processed

Expected behavior:

the system checks for the earliest usage in the bucket’s effective period,
if usage exists, a rerate is queued,
and the usage can be re-evaluated against the new shared bucket.

Usage Bucket Tiers #

Usage bucket tier updates can create rerates when the tier values used to calculate bucket consumption or charges change.

What this means is:

changing a bucket tier flat charge can create a rerate,
changing a threshold can create a rerate,
changing the usage unit can create a rerate,
threshold and unit changes update daily thresholds before the rerate is queued,
the related bucket must have usage,
and when the bucket is part of a share plan, the system checks that the bucket is bucketable.

Example:

A usage bucket tier has a threshold of 100 GB
Usage has already consumed bucket allowance in the current period
The threshold is changed to 50 GB

Expected behavior:

the system updates the threshold context,
queues a rerate from the bucket’s effective date,
and reprocesses the affected usage against the new tier configuration.

Share Plans #

Share plan changes can create rerates because share plans can change which accounts, services, packages, product codes, and usage buckets participate in entitlement consumption.

What this means is:

creating an account share plan can create rerates when participating services already have unbilled usage,
adding or changing share plan contributions can create rerates,
deleting a product-code participation can update contributions and create a rerate when contribution values change,
updating share plan participation limits or units can create a rerate,
contribution changes update daily thresholds before rerating so bucket size is correct,
and usage-invoicer share levels can require a parent-and-children rerate.

Example:

A share plan is added to an account after usage has already been processed
Existing services participate in the new share plan
The share plan bucket can apply to that usage

Expected behavior:

the system creates or updates the required threshold records,
checks whether the share plan has usage or bucketable value,
and queues a rerate so the previous usage can be evaluated against the new share plan.

Account Price Plans And Usage Rate Overrides #

Account price plan and usage rate override changes can create rerates when they affect the rate used for existing usage.

What this means is:

updating the start date of an account price plan can create a rerate,
updating the end date of an account price plan can create a rerate,
account price plan date rerates are created when the account price plan has overridden rates,
creating a package service price plan usage rate override can create a rerate,
updating a usage rate override amount or usage unit can create a rerate,
and the system checks for affected unbilled usage before creating override-based rerates.

Example:

An account price plan has a usage rate override
Usage has already been processed for October
The account price plan start date is moved from November 1 to October 1

Expected behavior:

the system identifies the affected usage invoicer accounts,
queues a parent-and-children rerate from the earliest affected price plan date,
and usage can be recalculated using the corrected account price plan timing.

Bill Runs And Scheduled Rerates #

Bill runs and scheduled rerates are important, but they are slightly different from the configuration-change triggers above.

What this means is:

automatic configuration changes generally create pending rerate records,
a scheduled rerate or manual rerate starts processing through a rerate schedule,
a bill run checks whether pending or failed rerates exist before billing continues,
if pending rerates exist for the bill run scope, the bill run can move into rerating status while those rerates are scheduled and processed,
and once rerating is complete, billing can continue with the recalculated usage context.

This distinction matters because a bill run usually does not decide the original rerate reason. It collects and processes rerates that were already created by earlier changes or manual requests.

What You Should Expect To See #

From an operations perspective, the visible results are:

pending rerate records can appear after relevant configuration changes,
each rerate has a start date,
each rerate has a reason such as Account Service Updated, Account Package Updated, Account Service Usage Bucket Updated, or User Initiated,
a rerate can be parent-only or parent-and-children,
the Usage Rerates screen can be used to monitor rerate schedules and progress,
and bill runs may wait for pending rerates to complete before continuing.

Why This Matters #

Usage rerating is important because usage charges depend on the full rating context that was true at the time usage should have been rated.

It allows businesses to:

correct service and package timing after usage has arrived,
apply updated bucket and share plan rules to affected usage,
correct account price plan and usage rate override timing,
keep bill runs from using stale usage-rating results,
and give operations teams a clear reason for why usage was recalculated.

The practical benefit is predictability. When a rerate appears, the reason should point back to the business event that changed how existing usage needed to be interpreted.

Still stuck? How can we help?