Rerate-Triggering Changes, RerateNow API, And Monitoring

Last verified with: 10.8.6.0

There is not a dedicated portal button or menu option that forces an arbitrary usage rerate. In the portal, rerate work is created by making an account, product, rate, bucket, share-plan, or price-plan correction that affects previously processed usage, then monitoring the resulting rerate activity from Operations / Usage Rerates.

When a user or integration needs to force a rerate for an account without relying on a portal configuration change, use the RerateNow API option described in this guide.

Overview #

A usage rerate tells LogiSense Billing to rate previously processed usage again because the rating context has changed.

The Usage Rerates screen is the portal screen used to review rerate schedules and processing progress. It shows which rerate schedules have been created, which accounts are included, why each rerate occurred, and whether processing has completed.

The screen is a monitor. It does not expose a direct button for creating an arbitrary rerate schedule. Rerate activity is created either when a user saves a rating-impacting change on the relevant account or setup screen, or when a user or integration starts a rerate through the RerateNow API.

When To Use This Workflow #

Use this workflow when a user needs to correct setup that may affect already processed usage.

Common examples include:

• correcting an account package effective date or effective cancel date,
• correcting an account service effective date or effective cancel date,
• adding or changing a usage bucket,
• updating a usage bucket tier,
• changing share-plan contribution or participation setup,
• updating account price plan dates,
• or correcting usage rate overrides in an account price plan.

Do not start with the Usage Rerates screen when the underlying setup is still wrong. Correct the account or configuration first, then use Usage Rerates to confirm the resulting rerate activity.

Before You Begin #

Confirm the following before making the change:

• You know which account or configuration record needs correction.
• You know the earliest usage period that may be affected.
• You have permission to edit the relevant account or setup screen.
• You understand whether child accounts, shared usage, buckets, or share plans may be affected.
• You can monitor the result from Operations / Usage Rerates.

The rerate start shown in Usage Rerates should align with the earliest affected usage date or usage period. Earlier corrections can cause more usage to be reset and reprocessed, so review date changes carefully before saving.

Create Rerate Activity From A Portal Change #

1. Open the account or setup screen where the rating-impacting correction needs to be made.
2. Select the record that needs to be corrected.
3. Update only the fields needed for the correction.
4. Review any warning that says the change will affect the current usage period and cause a rerate.
5. Confirm the warning only when the change is intentional.
6. Save the record.
7. Go to Operations / Usage Rerates.
8. Select the newest rerate schedule in the left panel.
9. Review the schedule and summary grid to confirm the expected account, rerate start date, reason, and processing state.
10. Use Refresh to reload the selected schedule until processing completes.

Force A Rerate With RerateNow API Call #

Use RerateNow when a specific usage invoicer account needs to be rerated from a specific date and there is no portal configuration change to save.

Call:

POST http://<host>/ResourceServer/api/v12/Rerate/Now
Authorization: Bearer <access_token>
Content-Type: application/json
{
  "accountId": 153,
  "rerateStart": "2026-06-01"
}

Payload fields:

Example using account name instead of account ID:

{
  "accountName": "Acme Corp",
  "rerateStart": "2026-06-01"
}

Expected behavior:

• the system creates a rerate schedule,
• the account rerate is recorded with the reason User Initiated,
• the rerate scope is Parent and Children,
• usage on or after rerateStart is eligible for rerating,
• and the schedule can be monitored from Operations / Usage Rerates.

The account must be a usage invoicer account. If a child account is supplied, the request is rejected and reports the account’s usage invoicer.

Always provide rerateStart when forcing an account rerate. If an account is provided without rerateStart, the system defaults the start date to 1753-01-01, which effectively asks the platform to rerate from the beginning.

Account Package Changes #

Use the account package screen when the correction relates to package timing or package participation.

1. Open the customer account.
2. Go to the account package area.
3. Select the package that needs correction.
4. Update the effective date, effective cancel date, or related package setting.
5. Confirm any rerate warning that appears.
6. Save the package.
7. Monitor the resulting schedule in Operations / Usage Rerates.

Expected behavior:

• the rerate reason may show as an account package change,
• the rerate start should reflect the affected period,
• and the summary grid should show the affected account after the schedule is processed.

Account Service Changes #

Use the account service area when the correction relates to service timing or service participation.

1. Open the customer account.
2. Go to the account package or service area where the service is maintained.
3. Select the service that needs correction.
4. Update the effective date, effective cancel date, or related service setting.
5. Confirm any rerate warning that appears.
6. Save the change.
7. Monitor the resulting schedule in Operations / Usage Rerates.

Expected behavior:

• the rerate reason may show as an account service change,
• usage in the affected period can be re-evaluated,
• and completed rows in the summary grid indicate that processing has finished for the account.

Usage Bucket Or Bucket Tier Changes #

Use the usage bucket or bucket tier setup when the correction changes allowance, bucket timing, thresholds, units, or bucket pricing behavior.

1. Open the account service, package, or setup screen where the bucket is maintained.
2. Select the usage bucket or bucket tier that needs correction.
3. Update the effective date, effective cancel date, threshold, unit, flat charge, or other affected bucket setting.
4. Confirm any rerate warning that appears.
5. Save the change.
6. Monitor the resulting schedule in Operations / Usage Rerates.

Expected behavior:

• the rerate reason may show as a usage bucket or bucket tier update,
• previous usage can be reprocessed against the corrected bucket rules,
• and the summary grid shows whether the affected account was queued and processed.

Share Plan Changes #

Use share-plan screens when the correction affects shared usage, contributions, participation limits, product-code participation, or share-plan add-ons.

1. Open the customer account.
2. Go to the share plan area.
3. Select the share plan that needs correction.
4. Update the contribution, participation, add-on, or related share-plan setting.
5. Confirm any rerate warning that appears.
6. Save the share plan.
7. Monitor the resulting schedule in Operations / Usage Rerates.

Expected behavior:

• the rerate reason may show as a share plan change,
• parent and child account usage may be affected when shared usage crosses account boundaries,
• and the summary grid helps confirm which account was included in the rerate schedule.

Account Price Plan And Usage Rate Override Changes #

Use account price plans when the correction affects account-specific pricing or usage rate overrides.

1. Open the customer account.
2. Go to Account / Profile / Price Plans.
3. Select the price plan that needs correction.
4. Update the price plan dates or the relevant usage rate override.
5. Confirm any rerate warning that appears.
6. Save the price plan.
7. Monitor the resulting schedule in Operations / Usage Rerates.

Expected behavior:

• the rerate reason may show as an account price plan or rate override change,
• usage in the affected period can be recalculated using the corrected rate context,
• and the schedule should move through queued, in-progress, and completed states.

Monitor The Rerate #

1. Go to Operations / Usage Rerates.
2. Select the newest rerate schedule in the left panel.
3. Review the schedule status, schedule start date, schedule complete date, and created-by user.
4. In the rerate summary grid, review the account, rerate start date, start date, queued date, complete date, reason, queued flag, and processed flag.
5. Use Refresh to reload the selected schedule and check the latest state.

The schedule status shows the overall lifecycle:

What Users Should Expect #

After saving a rerate-triggering change or calling RerateNow, users should normally see:

• a rerate schedule in Operations / Usage Rerates,
• one or more account-level rows in the summary grid when affected usage is found,
• a reason that describes the configuration change that caused the rerate, or User Initiated for RerateNow,
• a rerate start date based on the affected usage period,
• queued and processed indicators as rerating progresses,
• and a completed schedule when processing finishes.

Some schedules can complete without account-level rows if no eligible pending rerate work is found.

Troubleshooting #

Result #

After the rerate completes, the affected usage is reprocessed through the normal rerating flow. The Usage Rerates screen provides the operational record of which schedule ran, which accounts were included, why the rerate occurred, when processing started, and whether it completed successfully.