ForHosting KIT · Developer Utilities

Subscription plan change proration calculator

This subscription plan change proration calculator shows the financial effect of switching a customer between plans before the current billing cycle ends.

● BetaFree · in your browser
Use it from WebAPIEmailTelegramApp soon

Enter the full-cycle prices for the current and new plans, the number of unused days, and the total cycle length. The result separates the credit returned for unused time from the charge applied for the same period on the new plan, then reports the net amount and whether it is a charge, a credit, or no adjustment.

Enter comparable plan prices and cycle dates

Use the price of each plan for one complete billing cycle. Both prices must use the same currency and the same cycle basis, so compare monthly with monthly or annual with annual. Enter the total number of whole days in the active billing cycle, then enter the whole days remaining at the moment the change takes effect. If the switch happens at the end of the cycle, days remaining can be zero and every adjustment will be zero. The calculator rejects a remaining-day count larger than the complete cycle because that timing is internally inconsistent. It also rejects negative prices, fractional day counts, non-finite values, and a cycle length below one day. Taxes, discounts, account balance, usage charges, and payment processing are intentionally outside this calculation. If those items apply, calculate the base plan adjustment here first, then apply your billing policy in a separate, auditable step. This separation makes it easier to explain the result to a customer and reconcile it against an invoice.

Understand the credit, charge, and net amount

The unused fraction is days remaining divided by total billing-cycle days. The prorated credit multiplies the current plan price by that fraction, representing the value of service paid for but not used. The prorated charge multiplies the new plan price by the identical fraction, representing the cost of providing the replacement plan during those same days. Each monetary component is rounded to two decimal places before the net amount is calculated, matching a common invoice-line workflow. The net amount is the prorated charge minus the prorated credit. A positive net amount has the direction charge, meaning the customer owes the difference for an upgrade. A negative net amount has the direction credit, meaning the account should receive the absolute value for a downgrade. Zero has the direction none. The response keeps credit and charge as non-negative line items, while the signed net amount communicates the final balance clearly.

Apply the result consistently in billing operations

Use the output as a transparent calculation record rather than treating only the net amount as a mysterious adjustment. Store the original four inputs alongside the unused fraction, prorated credit, prorated charge, net amount, and direction. That gives support and finance teams enough information to reproduce the calculation without reconstructing dates later. Before posting invoice lines, confirm whether your organization counts the effective date as used or unused, because that policy determines days remaining. Also confirm whether your billing system prorates by calendar seconds instead of whole days; this capability deliberately uses whole days and should not be mixed with a second-based policy. For tax-inclusive prices, determine whether local rules require crediting tax separately. For discounted subscriptions, supply the actual applicable full-cycle plan prices if the discount should participate in proration. The API costs $0.002 per calculation and uses no network service, current date, or stored state, so identical validated inputs always produce identical results.

Quote a mid-cycle upgrade

Show a customer the unused-plan credit, replacement-plan charge, and additional amount due before confirming an upgrade.

Process a subscription downgrade

Calculate the account credit created when a lower-priced plan replaces the current plan for the remaining days.

Reconcile billing adjustments

Reproduce invoice proration from stored plan prices and cycle-day inputs during finance or support review.

What does the calculation cost?

Each API calculation costs $0.002. The browser version can run locally on this page.

How is the prorated credit calculated?

The current full-cycle plan price is multiplied by days remaining divided by total billing-cycle days, then rounded to two decimal places.

How is the prorated charge calculated?

The new full-cycle plan price is multiplied by the same unused fraction and rounded to two decimal places.

What does a negative net amount mean?

It means the prorated credit is larger than the prorated charge. The direction is credit, and the absolute net amount is the credit value.

Can days remaining exceed the billing cycle length?

No. That input is inconsistent and returns an invalid input error instead of calculating an adjustment. Taxes and discounts are not added automatically; supply the applicable plan prices and handle tax according to your billing policy.

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

POSThttps://api.kit.forhosting.com/ecom/subscription-proration-calc

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.

curl -X POST https://api.kit.forhosting.com/ecom/subscription-proration-calc \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"current_plan_price":30,"new_plan_price":60,"days_remaining":10,"billing_cycle_days":30}'
{
  "current_plan_price": 30,
  "new_plan_price": 60,
  "days_remaining": 10,
  "billing_cycle_days": 30
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "ecom.subscription_proration_calc",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

HTTPCodeMeaning
401unauthorizedMissing or invalid API key.
402insufficient_balanceYour balance doesn't cover the task price.
404unknown_typeThat task type doesn't exist.
429rate_limitedToo many requests. Use the webhook instead of polling.

Read the full KIT documentation →