Proration for Upgrades, Downgrades and Mid-Cycle Changes

Proration is where billing platforms quietly differ most, and where the difference reaches your customers fastest. A customer upgrades on day twelve of a thirty-day cycle. What do they owe, when, and what does the next invoice say? Every platform answers differently, and some answer differently depending on which screen you use.

This is the mechanics, the edge cases that produce support tickets, and what to test before you commit to a platform.

The basic calculation

Proration on an upgrade has two halves: credit the unused portion of what the customer already paid for, and charge the used portion of what they are moving to. On day 12 of 30, moving from a €20 plan to a €50 plan, the customer has 18 days unused at €20 (€12 credit) and 18 days to come at €50 (€30 charge), so €18 is due now and €50 is due at the next renewal.

That is the arithmetic everyone agrees on. Everything below is where platforms diverge.

The decisions a platform has to make

What is a month? Thirty days, the actual days in the calendar month, or a fraction of a year? A platform that treats every monthly cycle as 30 days is simpler and slightly wrong in February; one that uses real calendar lengths is correct and produces prorated amounts that differ month to month for the same change. Both are defensible. Pick one and make sure your invoices explain it.

Does the change day count as used or unused? A one-day difference on a €20 plan is small; on a €400 dedicated server it is a support ticket.

Does the cycle reset? Two models: the renewal date stays where it was and only the amount changes, or the upgrade starts a fresh cycle from today. The first keeps all a customer's services on one billing date, which is what most people want. The second is easier to explain on a single invoice and harder to manage across ten services.

Non-monthly cycles. An annual subscription upgraded in month seven produces a large prorated charge. Make sure the number that appears is the one you meant, and that quarterly, semi-annual and annual cycles are handled by the same code path rather than three approximations.

Setup fees. Generally should not be prorated, and generally should not be charged twice when a customer moves between plans. Check both.

Downgrades are the harder half

Upgrades are easy because the customer pays you. Downgrades are where policy has to be explicit, and where most complaints come from.

The defensible default is that downgrades apply at the next renewal, not immediately. The customer keeps what they paid for until the period ends, then bills at the lower rate. No refund is owed, nothing is clawed back, and the customer gets the service they bought.

The trap is the gap between what the interface promises and what the renewal actually does. If the portal says "applies at renewal", then the renewal invoice has to carry the new price. This sounds trivial and it is a real class of bug: a scheduled downgrade that is applied after the renewal has already been generated bills the old amount for one more cycle, and the customer notices. If your platform supports scheduled downgrades, test one across a renewal boundary before you trust it.

The alternative — immediate downgrade with a credit — is legitimate but has consequences. Credit balances accumulate, they have to be spendable against future invoices, and in some jurisdictions an unspent balance is a liability you owe rather than revenue you booked. We went through that in credit notes, refunds and clawbacks.

The hosting-specific cases

Hardware changes. On a dedicated server, an upgrade may mean a different physical machine. The proration is the easy part; the hard part is the old machine returning to inventory, the IP allocations following the service or being released, and the invoice line pointing at the right asset afterwards.

Add-ons mid-cycle. Extra IPs, extra storage, extra bandwidth. These need the same proration logic as the base product, and per-month add-on prices have to be scaled correctly when the parent service is on a quarterly or annual cycle. A per-month price multiplied onto an annual cycle without conversion is a factor-of-twelve error, and it is not a hypothetical one.

Upgrades that fail to provision. The customer paid the prorated amount and the resize failed. Now the invoice says one thing and the hypervisor says another. Covered in when provisioning fails after payment.

What to test before you buy

• Upgrade on day 12 of a 30-day cycle. Check the credit, the charge, the due date and the next renewal amount.
• Upgrade an annual service in month seven. Check the number is sane and the renewal date did not move unexpectedly.
• Schedule a downgrade, then let the renewal run. Confirm the invoice carries the new price, not the old one.
• Add an add-on to a service on an annual cycle. Confirm the per-month price was scaled to the cycle.
• Upgrade twice in one cycle. Confirm the second calculation uses the first upgrade as its baseline.
• Read the resulting invoice as a customer would. If you cannot explain the lines in one sentence, your support team will be explaining them all year.

How FluxBilling fits

Proration is a dedicated calculation module in FluxBilling with no side effects — inputs in, numbers out — so upgrade pricing is deterministic and testable rather than assembled inline at the point of sale. Hourly, monthly, quarterly, semi-annual and annual cycles all run through the same path, and per-month add-on prices are scaled to the parent cycle rather than added raw. Scheduled downgrades are applied before renewal invoices are generated in the daily lifecycle run, specifically so that a renewal lands on the post-downgrade amount and the portal's "applies at renewal" promise holds.

Products carry their own upgrade pricing configuration, and on bare metal an upgrade that moves the customer to different hardware goes through the same allocation and IPAM path as a new order, so the old machine returns to inventory and addresses follow the service rather than being stranded.

See billing features and current pricing.

Closing thoughts

Proration is not a feature customers ask about and it is a feature they notice. The platforms that get it right are the ones where the calculation is one piece of code used by every path, rather than something the upgrade screen, the API and the admin panel each work out for themselves. Test the six cases above on real data; the answers will tell you more than a feature comparison will.