Plan changes and pro-rata: upgrades priced fairly, automatically

What does the capability do?

It makes moving between plans a routine, correctly-priced event instead of a manual adjustment with a calculator.

• One calculation, every trigger. The pro-rata logic is shared code inside the billing layer: the price difference multiplied by days remaining in the period over days in the month. Whether the change comes from the admin, the member, or an API integration, the charge is identical.
• Upgrades charge, downgrades do not. An upgrade produces an immediate pro-rata charge for the richer plan’s remainder of the period. A downgrade simply takes the lower fee forward, avoiding the goodwill-burning micro-refunds that mid-period downgrade charges create.
• Scheduled changes. A member-level change can carry an effective-from date. Billing reads the scheduled values only once the date arrives, the same substitution mechanism that powers scheduled price changes at package level.
• The same orchestration as every lifecycle event. Plan changes run through the account-update strategy layer shared with signup, freezes, and cancellations, committing atomically so a failed change leaves nothing half-applied.

Why shared logic is the headline

Pro-rata bugs are rarely wrong formulas; they are the same formula implemented three times. When the admin flow, the member flow, and the overnight billing job each carry their own arithmetic, they drift, and the drift surfaces as a member disputing a charge that staff cannot reproduce. Centralising the calculation in one billing path, used by every lifecycle event, removes the drift by construction. It is the same design decision behind the platform’s freeze handling, and it is why the Billing Engine can treat plan changes as ordinary events rather than special cases.

Why it matters

Plan changes are a growth lever: members who can move up a tier in one click do, and members who can step down instead of cancelling stay. Both only work commercially when the pricing at the boundary is trustworthy. Pro-rata from shared logic, scheduled changes with clean effective dates, and atomic commits make the boundary boring, which is exactly what a member expects it to be.