Commet
  • Pricing
Log InTry out

What is Proration in SaaS Billing?

Proration calculates fair charges when a customer changes plans mid-billing cycle, crediting unused time on the old plan and charging for remaining time on the new one.


Proration is the calculation that happens when a customer changes their subscription plan in the middle of a billing cycle. Instead of waiting until the next renewal to apply the new price, the system credits the customer for the unused portion of their current plan and charges them for the remaining portion at the new plan's price. The result is a fair, day-level adjustment that takes effect immediately.

How proration works

The math is straightforward. When a customer upgrades mid-cycle, two things happen simultaneously: a credit for the days remaining on the old plan and a charge for those same days at the new plan's rate.

Here is a concrete example. A customer is on the Starter plan at $29/month. Their billing cycle is 30 days. On day 15, they upgrade to the Pro plan at $99/month.

Step 1: Credit for unused time on Starter. The customer has 15 days remaining. The daily rate on Starter is $29 / 30 = $0.967/day. The credit is 15 days x $0.967 = $14.50.

Step 2: Charge for remaining time on Pro. The daily rate on Pro is $99 / 30 = $3.30/day. The charge is 15 days x $3.30 = $49.50.

Step 3: Net amount. The customer pays $49.50 - $14.50 = $35.00 to upgrade immediately, and their next full renewal will be $99.

This calculation ensures the customer never double-pays for the same days. They paid for 15 days of Starter at the beginning of the cycle, get that back, and pay the Pro rate for the remaining 15 days.

When proration applies

Not every plan change triggers proration. The rules depend on the direction of the change and the starting point.

Upgrades are prorated immediately. When a customer moves to a higher-priced plan, proration kicks in right away. The customer gets instant access to the new plan's features, and the billing adjustment happens on their current invoice.

Downgrades are not prorated. When a customer moves to a lower-priced plan, the change takes effect at the next renewal. The customer keeps their current plan's features for the remainder of the billing period and starts the cheaper plan when the new cycle begins. This avoids the awkward scenario of issuing a credit that exceeds the new plan's charge (which would require a refund to the payment method).

Free to paid is not prorated. If a customer on a free plan upgrades to a paid plan, there is no proration because a $0 plan produces a $0 credit. The customer simply pays the full price of the new plan for the first partial or full period.

For a detailed walkthrough of every plan change scenario, see the guide on what happens when a customer changes plans.

Why proration matters

Without proration, you have two bad options when a customer wants to upgrade.

Option one: charge the full new plan price immediately and let the customer lose the unused time on their old plan. This feels unfair and generates support tickets.

Option two: schedule the upgrade for the next renewal date. This means the customer has to wait days or weeks to access the features they want, which hurts conversion from lower to higher plans.

Proration eliminates both problems. The customer gets immediate access, pays a fair price, and the billing system handles the math automatically.

Proration and addons

Addons follow the same proration logic as plan upgrades. When a customer activates an addon mid-cycle, they pay a prorated amount for the remaining days in the current period. At the next renewal, the addon's full price is added to the invoice.

For example, a customer with 10 days remaining in their billing cycle activates a $30/month addon. They pay $10 immediately ($30 / 30 days x 10 remaining days). On their next renewal invoice, the full $30 addon charge appears alongside the plan's base price.

Edge cases in proration

Proration calculations have a few details that matter at scale.

Day calculation. Proration uses the actual number of days in the billing period, not a fixed 30-day assumption. A February billing cycle has 28 or 29 days. A billing period from January 15 to February 15 has 31 days. The daily rate adjusts accordingly.

Multiple changes in one cycle. If a customer upgrades from Starter to Pro on day 10 and then from Pro to Enterprise on day 20, each change produces its own proration calculation. The second proration credits the unused Pro days (not the original Starter days) and charges the Enterprise rate for the remaining period.

Rounding. Proration amounts are calculated to the cent. Because of rounding, the sum of prorated charges across a full billing period might differ from the plan price by a cent. This is standard and expected.

Related

  • Billing Cycle: the period between two invoice dates, the window within which proration is calculated
  • Subscription Billing: recurring charging model where proration enables mid-cycle changes
  • Recurring Billing: automated collection at regular intervals
  • What Happens When a Customer Changes Plans: detailed guide covering every plan change scenario

Frequently Asked Questions

The system credits the unused days on the old plan and charges for the same days at the new plan's rate. For example, upgrading from $29/month to $99/month on day 15 of a 30-day cycle produces a $14.50 credit and a $49.50 charge, netting $35.00.

No. Downgrades take effect at the next renewal. The customer keeps their current plan's features for the rest of the billing period and starts the lower-priced plan when the new cycle begins.

Yes. When an addon is activated mid-cycle, the customer pays a prorated amount for the remaining days in the current period. The full addon price applies starting at the next renewal.

Developers

  • Documentation
  • Templates
  • GitHub

Resources

  • Blog
  • Changelog
  • Pricing

AI

  • Agents
  • MCP Server
  • Agent Skills
  • Claude Code
  • Codex

Learn

  • Guides
  • Glossary
  • Solutions
  • Billing for AI Models
  • Comparison

Company

  • About
  • Terms
  • Privacy
XLinkedInGitHub