Online School, Messy Billing, and the Proration Rabbit Hole

Published: (June 6, 2026 at 11:28 AM EDT)
3 min read
Source: Dev.to

Source: Dev.to

While designing the database and Product Requirements Document (PRD) for an online school project, I ran into a problem I was not expecting. The school had multiple subscription plans. For simplicity, imagine: Live Class Plan:₦50,000 per term Video On Demand Plan: ₦30,000 per term Hybrid Plan (Live Classes + Video On Demand):₦70,000 per term. Initially this looked simple. Students subscribe. System charges them. Done. Then I asked: What happens if somebody changes plans halfway through the term? Suppose: A student already paid: Live Class Plan

₦50,000

Two months later: They decide: Upgrade to Hybrid Plan

Do we charge: ₦70,000 again?

That would be unfair. Do we charge: ₦20,000 difference?

Maybe. But what if they already used most of their subscription period? This question led me to something called: Proration Proration simply means: Charging customers only for the portion they actually use. Instead of pretending subscriptions always begin and end perfectly. Proration tries to answer: “How much value remains in the current subscription?” and “How much should the customer pay for the new one?” Assume: Term Length: 100 Days

Student buys: Live Plan

₦50,000

After: 40 Days

they upgrade. This means: Used: 40 Days

Remaining: 60 Days

Value remaining: Remaining Value

= Remaining Days / Total Days

= 60 / 100

= 60%

Remaining credit: 60% × ₦50,000

= ₦30,000

Hybrid costs: ₦70,000

Therefore: Amount to bill

= New Plan Price − Remaining Credit

= ₦70,000 − ₦30,000

= ₦40,000

Student pays: ₦40,000

instead of: ₦70,000

This feels fairer. What if: Hybrid user: ₦70,000

moves to: ₦30,000 plan

Should the system: Refund money? Create account credits? Apply discount later? Ignore downgrades until renewal? This is where: Proration Rules become important. Proration calculations are useless without rules. The business must decide: Options: Daily basis Weekly basis Monthly basis Example: Daily proration

usually produces more precise billing. Example: Immediately upgrade

Immediately bill difference

OR Upgrade at next renewal

Possible rules: Refund money Store credits Ignore until renewal Imagine: Hybrid includes: Live classes Recorded videos Assignments What if: Student already watched: 95% of videos

Should remaining credit still be full? Business rules become complicated quickly. Initially I thought: “I only need payment tables.” Eventually I realized: I also need to track: Subscription Table: id

student_id

plan_id

start_date

end_date

status

Plan Change Table: id

old_plan

new_plan

credit_applied

amount_charged

changed_at

Because billing decisions require historical information. Without history: You cannot calculate proration. The simplified version I now think about is: Remaining Credit

=

(Remaining Time / Total Subscription Time)

×

Current Plan Price

Then: Amount To Charge

=

New Plan Price

Remaining Credit

Simple formula. Complicated business rules. Initially I thought subscriptions meant: User Pays

→ Access Granted

What I discovered was: Subscriptions are mostly: Business Rules

Edge Cases

Lots Of Questions

Proration taught me something important: Billing systems are rarely difficult because of mathematics. They are difficult because products have rules. Now whenever I design subscription systems I ask: “What happens when somebody changes their mind halfway through?” Because eventually: Somebody always does. Have you ever implemented subscriptions or billing logic? How would you handle upgrades and downgrades?

0 views
Back to Blog

Related posts

Read more »

Mobile Midsommer Madness

!Cover image for Mobile Midsommer Madnesshttps://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploa...