Proration explained: how to calculate it, with examples

Proration is the billing concept most likely to generate a confused support ticket, because the invoice shows a number nobody typed anywhere: not the old plan price, not the new one, but some third amount with cents in it. Here is what that number is and how it is calculated. (For the short definition, see proration in the glossary.)

The idea in one sentence

When a subscription changes mid cycle, the customer should pay for exactly what they used: the old plan for the days they had it, the new plan for the rest. Proration is just that split, expressed as a credit and a charge.

A worked upgrade

Say a customer is on a $30 per month plan, their billing cycle runs from March 1 to March 31, and on March 11 they upgrade to a $60 plan.

The month has 31 days. On March 11 there are 21 days left, ten days used.

• Credit for the unused old plan: $30 × (21 / 31) = $20.32
• Charge for the new plan's remainder: $60 × (21 / 31) = $40.65
• Net difference: $40.65 minus $20.32 = $20.33

The credit and the charge are separate invoice lines, so each rounds on its own; that is why the net can be a cent off from computing the difference directly.

So the customer sees a charge of $20.33, a number that appears on no price list. Multiply that by a plan with seats, a coupon, and tax, and you can see why finance teams ask questions. The math is simple; the visibility usually is not. To run the same split on your own prices and dates, the free proration calculator works it out for you.

Downgrades: charge now or credit later?

A downgrade produces the reverse: the unused portion of the expensive plan is worth more than the remainder of the cheap one, so the customer is owed the difference. There are two honest ways to handle it. Apply it as a credit against the next invoice, which is what most businesses do, or refund it, which is rarer and usually reserved for cancellations. What matters is picking one policy and stating it, because a customer who expected a refund and got a credit writes in.

Many platforms, ours included, take a third path for timing: the prorated amounts from a mid cycle change can sit in a queue of pending charges and settle on the next regular invoice, instead of firing a tiny stand alone invoice the moment someone clicks upgrade. One invoice per period is easier on everyone, especially the customer's accounts payable.

The edge cases that bite

• Month lengths differ. A daily rate computed in February is not the same as one computed in March. Decide whether you prorate by calendar days of the actual period (most accurate) and stay consistent.
• Rounding. Each prorated piece produces fractional cents. Round each line once, at the end, with a consistent rule. Rounding intermediate steps compounds into totals that do not add up on inspection.
• Multiple changes in one cycle. A customer who upgrades, adds a seat, and downgrades in the same month generates a stack of small credits and charges. Each needs to reference what it covers and for which date range, or the invoice becomes unreadable.

The real fix is showing the work

Every proration dispute comes down to the same thing: the invoice shows $20.33 and nothing else. The fix is an invoice that can answer for itself. In yRecurring every prorated line shows how it was worked out: the date the change happened, the day counts, the daily rates, the credit, the charge, and the single rounding step, one click from the invoice. Support conversations about proration get short when both sides are reading the same calculation.

If you want to see it, the trial takes no card: set up a plan, upgrade it mid cycle, and open the calculation on the resulting line. The eight pricing models page covers the plans you can prorate between, and subscription billing for software companies shows seat and plan changes in a SaaS setting.