Subscription proration
Upgrades mid-period: credit the unused, charge the new prorated, settle the difference.
By Solomon Ajayi · Free to read, no signup
A user is on your ₦1,000/month plan. On day 15 of a 30-day month, they upgrade to ₦2,000/month. They've already paid ₦1,000 for this month and used half of it. Two things must happen: credit them for the ₦500 they didn't consume of the old plan, then charge them prorated ₦1,000 for the rest of the month at the new plan rate. Net: they pay you another ₦500 today. This 'pay the difference' shape is what every SaaS-shaped fintech ships. The math lives in your application layer; the ledger reflects the NET effect on cash and deferred revenue.
A subscription payment is not revenue the day it arrives. The user has paid for thirty days of service they have not received yet, so the cash lands in Deferred Revenue, a liability, and you recognize it into Subscription Revenue a little at a time as the days are consumed. By day fifteen, half the month is earned and half still sits deferred. That deferred balance is the obligation you owe them, and it is the thing an upgrade has to adjust.
Proration is just reconciling that obligation against a new plan rate. You credit back the ₦500 of unused old-plan service and charge ₦1,000 for the remaining half-month at the new rate. The day-by-day arithmetic, unused days times old rate, remaining days times new rate, belongs in application code. The ledger only needs the two net numbers that fall out of it: cash changes by ₦500 and Deferred Revenue changes by ₦500.
After the upgrade entry, Deferred Revenue holds ₦1,000, which is fifteen remaining days at the new ₦2,000 monthly rate, and that balance keeps amortizing into revenue exactly as before. The ledger never sees 'a plan change' as a concept; it sees a cash receipt and a shift in what you still owe. Keeping it that simple is what lets the same two-account pattern handle upgrades, downgrades, and mid-cycle switches without new machinery.
Worked example, step by step
Day 1: User pays ₦1,000 for the current month
Standard subscription payment. The full ₦1,000 becomes deferred revenue, you owe the user 30 days of service in exchange.
| Account | Debit | Credit |
|---|---|---|
| Bank Account (1200) | ₦1,000.00 | |
| Deferred Revenue (2400) | ₦1,000.00 |
Bank UP ₦1,000. Deferred Revenue (liability) UP ₦1,000. ZERO revenue recognized yet, see Lesson 10 for the foundational pattern.
Day 15: Recognize the first half-month of revenue (₦500)
Half the month is consumed. ₦500 of deferred revenue moves to recognized revenue. The other ₦500 sits as deferred, they're entitled to 15 more days of service.
| Account | Debit | Credit |
|---|---|---|
| Deferred Revenue (2400) | ₦500.00 | |
| Subscription Revenue (4000) | ₦500.00 |
Deferred Revenue DOWN ₦500 (reclassified). Subscription Revenue UP ₦500 (earned). Bank UNCHANGED. This is the standard monthly amortization, see Lesson 10 again. The state after this entry is the STARTING POINT for the proration in step 3.
Day 15: Upgrade to ₦2,000/month, settle the proration
User upgrades. Math: credit them ₦500 for the unused half of the old plan, charge them ₦1,000 for the prorated half of the new plan. Net new charge: ₦500. Net Deferred Revenue change: +₦500 (cancel old ₦500, add new ₦1,000).
| Account | Debit | Credit |
|---|---|---|
| Bank Account (1200) | ₦500.00 | |
| Deferred Revenue (2400) | ₦500.00 |
Bank UP ₦500 (user pays the difference). Deferred Revenue UP ₦500 (net of old refund + new charge). Two-line entry that compresses the full proration math. After this: Deferred Revenue holds ₦1,000 (15 days at the new ₦2,000 monthly rate), Bank up ₦500 net for the upgrade.
Takeaway
Subscription proration compresses to a net change in cash + a net change in deferred revenue. The day-by-day math (compute unused days × old rate, plus remaining days × new rate, find the delta) happens in application code. The LEDGER just reflects the net. Engineers who try to model every prorated day as its own ledger entry drown in noise; engineers who skip the proration entirely and just charge the full new plan immediately overcharge users and trigger refund storms. Compute the net in app code, post the net to the ledger, move on.
Practice this on a real ledger
Reading is half of it. Open this lesson in the lab to post the entries yourself against a real Postgres-backed double-entry ledger, with the validation on. Free, your sandbox is yours.