Billing
Proration Rules That Don't Generate Support Tickets
Mid-cycle upgrades, downgrades, seat changes and refunds each need a stated rule. Where the rule is implicit, the invoice becomes a conversation.
Subscription billing is straightforward until something changes mid-cycle. Then a set of decisions has to be made — and if they were never made explicitly, they get made implicitly by whatever the billing code happens to do, which is how customers end up on the phone asking why their invoice is £43.17.
The decisions you have to make
• Upgrade mid-cycle: charge the difference immediately, or at next renewal?
• Downgrade mid-cycle: refund, credit, or take effect at renewal only?
• Added seats: prorated from the day added, or billed whole-period?
• Removed seats: credited, or held until renewal?
• Cancellation: service to period end, or immediate with a refund?
• Proration basis: calendar days, or a fixed 30-day month?
None of these has a universally right answer. All of them need one answer, written down, applied consistently, and visible to the customer before they act.
Defaults that cause the fewest problems
• Upgrades take effect immediately and are prorated by day — the customer gets more value now and expects to pay for it.
• Downgrades take effect at renewal, or produce account credit rather than a refund.
• Seats prorate by day in both directions.
• Cancellation runs service to the end of the paid period, with no refund.
• Prorate on actual calendar days, so February and August behave differently and honestly.
Credit rather than refund wherever you reasonably can. Cash that never leaves needs no approval.
Show the arithmetic on the invoice
Most proration disputes are not disputes about the amount; they are confusion about its derivation. Put the working on the line item — old plan credited for unused days, new plan charged for remaining days, both with the day counts and rates visible.
Decide the awkward cases in advance
Every billing system meets these eventually, and improvising is what produces inconsistency:
• Two plan changes in one cycle — prorate against the original, or the intermediate?
• An upgrade so late in the cycle that the prorated charge is trivial. Set a minimum-charge floor.
• A change that would produce a negative invoice. Cap at zero and carry the balance forward.
• Annual plans, where a mid-term change involves a much larger sum and probably needs a human.
• Tax, which must be recalculated on the prorated amount rather than the headline price.
Preview it before the customer commits
The most effective single feature is a preview: before confirming a plan change, show exactly what will be charged now and what the next full invoice will be. It converts a post-hoc complaint into an informed decision, and it is far cheaper to build than the support volume it prevents.
Test the boundaries
Write test cases for the first day of a cycle, the last day, a leap day, a month-end renewal date in a shorter month, and a same-day upgrade-then-downgrade. Those five cases account for most proration bugs that reach production, and all of them are cheap to assert against once the rules are actually written down.
Credit-don't-refund on downgrades removed most of our finance friction. Cash never leaves, the customer sees the value, and nobody has to approve a refund.
Showing the proration arithmetic on the invoice line was the single biggest reduction in billing tickets we've had. People aren't angry about the number, they just can't see where it came from.