Subscription proration answer: to prorate a mid-cycle plan change, credit the old plan for the days left in the cycle (old price × remaining days ÷ total cycle days), charge the new plan for the same remaining days (new price × remaining days ÷ total cycle days), then subtract the credit from the new charge — the result is the exact amount due today.
What this tool does
This is a free, browser-only subscription proration calculator for SaaS billing changes. When a customer upgrades or downgrades mid-cycle, you owe them credit for the unused portion of the old plan and you charge them for the remaining portion of the new plan. This tool computes both amounts using the exact number of calendar days in the billing cycle you enter — 28, 29, 30 or 31 for a month, 365 or 366 for a year — instead of assuming every cycle is 30 or 30.44 days, which is the shortcut most spreadsheet formulas take and the reason they drift from what a real billing platform charges.
How to use it
Pick a cadence (Monthly or Annual) and enter the cycle start date; click "Auto-fill" to set the correct end date one calendar month or one calendar year later. Enter the date the plan actually changes, and the full-cycle price for the old and new plan. Click Calculate proration. The breakdown shows three lines, the same way a Stripe invoice preview does: the unused-time credit on the old plan, the prorated charge on the new plan, and the net amount due today — negative means the customer is owed a credit instead of being charged.
Example 1 — mid-month upgrade (real numbers)
Input
Cadence: Monthly Cycle: 2026-07-01 → 2026-08-01 (31 days) Change date: 2026-07-16 Old plan: $10.00/mo New plan: $30.00/mo
Output
Days remaining after change: 16 of 31 Credit — unused time on old plan: -$5.16 (10.00 × 16/31) Charge — remaining time on new plan: +$15.48 (30.00 × 16/31) Net amount due today: $10.32
Example 2 — annual downgrade (real numbers)
Input
Cadence: Annual Cycle: 2026-01-01 → 2027-01-01 (365 days) Change date: 2026-07-01 Old plan: $1,200.00/yr New plan: $600.00/yr
Output
Days remaining after change: 184 of 365 Credit — unused time on old plan: -$604.93 (1200.00 × 184/365) Charge — remaining time on new plan: +$302.47 (600.00 × 184/365) Net amount due today: -$302.46 (credit to customer)
Why exact days instead of an average
A 30-day average denominator overcharges customers in 31-day months and undercharges in 28/29-day months — small per-customer, but systematic across thousands of invoices, and it will not match what Stripe or Chargebee actually billed if you are reconciling a support ticket. Using the real days_in_cycle from the two dates you entered keeps the math auditable: anyone can recompute price × days_remaining ÷ days_in_cycle by hand from the same two dates and get the same cents.
FAQ
How is subscription proration calculated exactly?
Proration compares two amounts over the days remaining in the current billing cycle after the change date. The unused-time credit on the old plan is old_price × (days_remaining ÷ total_days_in_cycle). The prorated charge for the new plan is new_price × (days_remaining ÷ total_days_in_cycle). The net amount due today is the new-plan charge minus the old-plan credit. This tool computes total_days_in_cycle and days_remaining from real calendar dates, not a fixed 30-day assumption.
What happens when I downgrade instead of upgrade?
The math is identical either direction. On a downgrade the new plan's prorated charge is usually smaller than the old plan's unused-time credit, so the net amount due today comes out negative, meaning the customer is owed a credit rather than charged. This tool labels that result as a credit so it reads the same way a Stripe invoice preview does.
Why does this differ slightly from a simple day-average calculator?
Many spreadsheet formulas assume every month is 30 days or every cycle is 30.44 days on average, which produces a systematically wrong total_days_in_cycle for any real month other than exactly 30 days. This tool takes the actual cycle start and end dates you enter, counts the real number of days between them (28 to 31 for a month, 365 or 366 for a year), and uses that exact denominator, matching how billing platforms like Stripe and Chargebee compute proration internally.
Does this handle annual billing cycles and leap years?
Yes. Choose the Annual cadence and the auto-fill button adds exactly one calendar year to the start date, so a cycle starting in a leap year correctly spans 366 days when it includes February 29, and 365 days otherwise. You can also type any custom start and end date directly for a non-standard cycle length; the day count is always derived from the two real dates, never assumed.
What if I change plans on the very first or last day of the cycle?
If the change date equals the cycle start date, days_remaining equals the full cycle length, so the old plan is credited in full and the new plan is charged in full for the entire period. If the change date equals the cycle end date, days_remaining is zero, so there is no credit and no new charge today; the new price simply applies starting with the next cycle.
Is my billing data uploaded anywhere?
No. All parsing, date math, and the credit/charge calculation run in plain JavaScript inside your browser. There is no server call, no analytics on the prices or dates you enter, and no network request after the page has loaded, so it is safe to use with real customer pricing.