# Prorated Billing Explained: How Proration Works for SaaS Subscriptions

> Prorated billing for SaaS - how proration is calculated on upgrades, downgrades, mid-cycle changes, and add-on seats, with examples and common implementation pitfalls.
- **Author**: Ayush Agarwal
- **Published**: 2026-06-01
- **Category**: Subscription Billing, SaaS
- **URL**: https://dodopayments.com/blogs/prorated-billing-explained-saas

---

Prorated billing is how subscription businesses charge customers for partial billing periods. When a customer upgrades mid-month, downgrades mid-month, adds users mid-month, or cancels mid-month, the billing system has to calculate a fractional charge or credit for the days actually used at each plan level - rather than charging a full month at the new rate or refunding the full month at the old rate.

Proration sounds simple. In practice it is one of the trickier parts of subscription billing because every billing event creates accounting consequences that have to be reconciled correctly. A typical SaaS billing system has to handle plan upgrades (charge the difference), plan downgrades (issue a credit or pro-rate the next invoice), seat additions (charge for the remaining period), seat removals (credit for the remaining period), trial conversions (charge from the conversion date), and mid-cycle cancellations (refund the unused portion or let the period run out).

This guide explains how proration works, walks through specific calculation examples for each scenario, and covers the implementation pitfalls that most SaaS founders eventually run into.

## What Proration Actually Calculates

The core proration calculation is the fraction of the billing period that is being charged or credited at a particular rate.

```
Prorated Amount = Plan Price x (Days Remaining / Days in Billing Period)
```

For a $100/month plan where the customer upgrades or adds something on day 10 of a 30-day month, there are 20 days remaining. The prorated amount for the remaining period is $100 x (20/30) = $66.67.

If the customer upgrades to a $200/month plan on day 10, the upgrade charge is the difference between what they would have paid for the rest of the period at the new rate ($200 x 20/30 = $133.33) and what they already paid for the rest of the period at the old rate ($66.67). The proration charge is $66.66.

This is the most common case in SaaS billing. Most billing platforms (Stripe, Chargebee, Recurly, [Dodo Payments](https://dodopayments.com/blogs/best-billing-platform-usage-based-pricing)) handle this calculation automatically based on the day of the billing cycle when the change occurs.

## Common Proration Scenarios

There are six common scenarios that any SaaS billing system needs to handle. Each has slightly different math.

### Scenario 1: Plan Upgrade Mid-Cycle

Customer on $100/month plan upgrades to $200/month plan on day 10 of a 30-day cycle.

- Already paid: $100 (for the full original month)
- Should have paid for first 10 days at old rate: $100 x 10/30 = $33.33
- Should pay for remaining 20 days at new rate: $200 x 20/30 = $133.33
- Net additional charge: $133.33 - ($100 - $33.33) = $66.66

The customer is charged $66.66 immediately. Their next regular bill (one month later) is for the full $200.

### Scenario 2: Plan Downgrade Mid-Cycle

Customer on $200/month plan downgrades to $100/month plan on day 10 of a 30-day cycle.

- Already paid: $200
- Should have paid for first 10 days at old rate: $200 x 10/30 = $66.67
- Should pay for remaining 20 days at new rate: $100 x 20/30 = $66.67
- Total should have paid: $133.34
- Credit owed to customer: $200 - $133.34 = $66.66

The credit typically appears on the next invoice rather than being refunded immediately. Some SaaS issue immediate refunds; most apply the credit to the next billing cycle to reduce processing costs.

### Scenario 3: Seat Addition Mid-Cycle

Customer on a $50-per-seat plan with 5 seats adds 2 seats on day 10 of a 30-day cycle.

- Current monthly cost: 5 x $50 = $250
- Add-on cost for 2 seats for 20 remaining days: 2 x $50 x 20/30 = $66.67

The customer is charged $66.67 immediately. Their next regular bill is for 7 x $50 = $350.

### Scenario 4: Seat Removal Mid-Cycle

Customer on a $50-per-seat plan with 7 seats removes 2 seats on day 10 of a 30-day cycle.

- Already paid: 7 x $50 = $350
- Should have paid for first 10 days: $350 x 10/30 = $116.67
- Should pay for remaining 20 days at new headcount: 5 x $50 x 20/30 = $166.67
- Total should have paid: $283.34
- Credit owed: $66.66

Same credit treatment as Scenario 2 - typically applied to the next invoice.

### Scenario 5: Trial Conversion Mid-Period

Customer on a 14-day free trial converts to a $99/month plan on day 7 of the trial.

- Pre-conversion: $0 paid (free trial)
- Post-conversion: Most SaaS bills the full $99 immediately and starts a new monthly cycle from the conversion date

A less common pattern is to bill prorated for the remaining 7 trial days as a "thank you" to the customer, but this is unusual because trial users have not paid anything and proration would just delay revenue.

### Scenario 6: Mid-Cycle Cancellation

Customer on $100/month plan cancels on day 10 of a 30-day cycle.

Two policies are common:

**Service-through-period-end (most common)**: The customer's access continues through day 30. No refund is issued. The customer's next bill (which would have occurred on day 30) is not generated. Their access ends at the period boundary.

**Immediate cancellation with refund**: The customer's access ends on day 10. A refund of $100 x 20/30 = $66.67 is issued.

Most SaaS uses the service-through-period-end policy because it is operationally simpler and customers generally do not expect refunds on monthly subscriptions. Refunds for canceled annual subscriptions are more common because the dollar amount is large enough to warrant the operational overhead.

## Day-Based vs Second-Based Proration

The examples above use day-based proration (dividing by days in the billing cycle). Some billing systems use second-based proration (dividing by seconds in the cycle) for higher precision.

For most SaaS, the precision difference is irrelevant. A customer who upgrades at 10:30 AM versus 4:30 PM pays essentially the same prorated amount. Day-based proration is simpler to explain, easier to audit, and aligns with how customers think about partial-month usage.

Second-based proration matters more for usage-based or metered billing where the underlying service usage is measured continuously. If a customer adds a seat at 10:30 AM, their usage on that seat starts at 10:30 AM, and second-based proration matches the actual usage timing. For our broader treatment of metered billing, see [usage-based billing](https://dodopayments.com/blogs/best-billing-platform-usage-based-pricing).

## Calendar Month vs Fixed-Length Cycles

Another implementation choice is whether the billing cycle aligns to calendar months (28-31 days depending on the month) or to fixed-length periods (always 30 days, regardless of calendar).

**Calendar-month billing** is most intuitive for customers. They signed up on the 15th, so they renew on the 15th. The number of days varies by month (January has 31, February has 28-29), which means the daily proration rate varies too. A $100 plan in January prorates at $3.23/day; in February (non-leap year), it prorates at $3.57/day.

**Fixed-length billing** treats every cycle as 30 days regardless of calendar. This makes daily rates constant but disconnects the billing cycle from calendar months over time. After 12 fixed cycles, the customer has been billed for 360 days, drifting 5+ days from the calendar.

Most SaaS uses calendar-month billing because the slight variation in daily rate is acceptable and customers expect calendar alignment. Some usage-based billing platforms use fixed-length cycles for accounting simplicity.

A pattern we see often at Dodo Payments: many teams underestimate the operational complexity of proration. The math itself is easy, but the edge cases multiply quickly. A mid-cycle upgrade combined with seat changes during a trial extension is the kind of compound case that breaks naive implementations - and the more pricing flexibility a SaaS offers, the more of these compound cases the billing system has to handle correctly.

## Implementation Pitfalls

Several proration pitfalls catch SaaS founders the first time they build subscription billing.

**Failing to handle the billing-cycle boundary correctly.** If a customer upgrades at 11:59 PM on the last day of their billing cycle, they should be charged the new full rate starting the next day, not a one-day proration. Off-by-one errors at cycle boundaries are common bugs.

**Double-billing on plan switches.** A naive implementation might charge for the new plan starting today while not crediting the unused portion of the old plan. The customer ends up paying for both plans for the overlap period.

**Not handling negative proration credits.** A customer downgrading from $500/month to $100/month on day 5 of a 30-day cycle is owed a credit larger than the next month's bill. The system needs to either issue a refund, carry the credit forward across multiple months, or limit credit to the next invoice (which can feel unfair to the customer).

**Inconsistent rounding.** $100 x 7/30 = $23.3333... Should that be $23.33, $23.34, or $23.3333 stored as a fraction? Inconsistent rounding across invoices accumulates small errors over time and eventually fails reconciliation. The standard is to round to two decimal places (cents) using banker's rounding (round half to even).

**Forgetting tax on prorated amounts.** VAT, GST, sales tax, and other consumption taxes apply to the prorated amount, not the full monthly rate. The tax calculation has to recompute based on the prorated charge, not just apply the same percentage to the original full rate.

**Missing the dunning interaction.** If a customer is in failed-payment state and upgrades, do you charge the upgrade immediately or wait until the failed payment is resolved? Most systems queue the upgrade until payment succeeds, but some allow the upgrade to push through, which can compound the failed-payment problem.

## How Proration Interacts with Invoicing

For SaaS that sends invoices (rather than charging cards automatically), proration creates additional invoicing decisions:

**Immediate invoice for the upgrade charge**: Send a separate invoice for the proration amount, due immediately. The customer pays this and the next regular invoice arrives one cycle later for the full amount.

**Pro-rate onto the next invoice**: Hold the upgrade charge until the next regular invoice and add it as a line item. Simpler administratively but delays revenue recognition.

**Credit memo for proration credits**: Downgrades and seat removals create credits. These can be issued as credit memos (formal accounting documents) or as adjustments on the next invoice. Credit memos are more transparent but more administratively heavy.

Most SaaS billing platforms offer configurable proration behavior. The right choice depends on the customer base - high-touch enterprise customers usually expect credit memos and separate invoices; self-serve SMB customers tend to be happy with rolled-forward credits.

## Proration in Annual Contracts

Annual contracts complicate proration because the billing period is 12 months instead of one month. The same math applies but the dollar amounts are much larger.

A customer on a $12,000 annual contract who upgrades to a $24,000 annual contract on day 60 of 365:

- Already paid: $12,000
- Should have paid for first 60 days at old rate: $12,000 x 60/365 = $1,972.60
- Should pay for remaining 305 days at new rate: $24,000 x 305/365 = $20,054.79
- Total should pay: $22,027.39
- Net additional charge: $22,027.39 - $12,000 = $10,027.39

The customer is invoiced for an additional $10,027.39 today. Their next renewal (in 305 days) is for the full $24,000.

For downgrades on annual contracts, the credit amounts can be large enough that customers expect refunds rather than credits applied to future periods. Most SaaS has explicit downgrade policies (sometimes called "true-up" or "true-down" provisions) that govern how credits are handled.

## Proration and Revenue Recognition

For SaaS that follows ASC 606 revenue recognition (which is most of them), proration creates revenue recognition mechanics that need to be handled correctly.

The basic principle is that revenue is recognized over the period the service is delivered, not when the cash is collected. A prorated upgrade charge for 20 days of service should generate 20 days of revenue recognition, not a one-time spike.

Most modern billing platforms integrate with accounting software (NetSuite, QuickBooks, Sage Intacct, Xero) and handle this automatically. The accounting close is much easier when the billing platform has done the revenue recognition math correctly upfront.

For a deeper look at SaaS revenue recognition, see our [deferred revenue explained](https://dodopayments.com/blogs/deferred-revenue-explained) and [billings vs revenue](https://dodopayments.com/blogs/billings-vs-revenue) posts.

## How Dodo Payments Handles Proration

Dodo Payments handles proration automatically as part of the subscription billing infrastructure. When a customer upgrades, downgrades, adds seats, or removes seats, the billing engine calculates the prorated charge or credit based on the day of the cycle and applies it correctly.

Specifically:

- **Calendar-month billing** with day-based proration is the default
- **Immediate billing for upgrades** generates an invoice for the proration amount at the time of the change
- **Credits for downgrades** are applied to the next invoice by default, with optional refund processing for larger credits
- **Tax recalculation** applies the correct VAT, GST, or sales tax to the prorated amount based on the customer's jurisdiction
- **Revenue recognition output** integrates with downstream accounting systems for ASC 606 compliance

The full mechanics are documented in the [subscription docs](https://docs.dodopayments.com/features/subscription). For SaaS founders building their own proration logic, the docs serve as a reference implementation showing how the edge cases (boundary timing, rounding, tax recalculation) should be handled.

## FAQ

### What is prorated billing?

Prorated billing is the practice of charging a customer for a fraction of a billing period based on actual usage. When a customer upgrades, downgrades, or adds users mid-cycle, the billing system calculates a proportional charge or credit for the days affected by the change. The formula is plan price multiplied by days remaining divided by days in the billing period.

### How is proration calculated on an upgrade?

On an upgrade, proration calculates the difference between the new plan's charge for the remaining days and what the customer already paid for those days at the old rate. For a customer on a $100/month plan who upgrades to $200/month on day 10 of a 30-day cycle, the upgrade charge is $200 x 20/30 - $100 x 20/30 = $66.66 charged immediately.

### Do customers get refunds on prorated downgrades?

It depends on the SaaS's downgrade policy. Most SaaS apply the prorated credit to the next invoice rather than issuing immediate refunds, which reduces processing costs. Some SaaS, especially for large annual contract downgrades, issue refunds directly. Some prepaid SaaS do not allow downgrades within a billing cycle at all, forcing the customer to wait until the next renewal.

### What is the difference between proration and partial refund?

Proration is a billing concept for charging or crediting partial billing periods, typically applied prospectively for the remaining days of a cycle. A partial refund is an accounting transaction returning money to the customer for value not received. Proration can result in a partial refund (when a customer downgrades and the policy is to refund), but they are not synonymous - proration is the calculation method, refund is one possible outcome.

### Do all billing systems handle proration the same way?

No. Billing systems differ on whether they use day-based or second-based proration, calendar-month or fixed-length cycles, immediate billing for upgrades or rolled-forward billing, and how they handle edge cases like trials, cancellations, and downgrade credits. Most SaaS platforms make these behaviors configurable. For SaaS using infrastructure like Dodo Payments, the defaults are designed to match SaaS billing norms, but specific behaviors can be customized.

## Conclusion

Proration is one of those parts of subscription billing that looks simple in theory and reveals its complexity in implementation. The math is straightforward - plan price times days remaining divided by days in the period. The complexity is in the edge cases, the accounting consequences, and the tax recalculation across jurisdictions.

For SaaS founders building subscription billing, the right move is usually to use a billing platform that handles proration as a built-in feature rather than implementing it from scratch. The marginal time invested in custom proration logic almost never pays back relative to using a battle-tested system.

[Dodo Payments](https://dodopayments.com) handles proration as part of subscription billing infrastructure, with the calendar-month, day-based, immediate-billing-for-upgrades default that fits most SaaS. See the [subscription documentation](https://docs.dodopayments.com/features/subscription) for implementation details or the [pricing page](https://dodopayments.com/pricing) for cost comparison against running billing in-house.
---
- [More Subscription Billing articles](https://dodopayments.com/blogs/category/subscription-billing)
- [All articles](https://dodopayments.com/blogs)