Lesson 10Accrual and engineering patternsIntermediate

Deferred revenue

Why annual subscriptions cannot all hit January's revenue.

By Solomon Ajayi · Free to read, no signup

A user pays you ₦12,000 in January for an annual subscription. Your instinct: book ₦12,000 of January revenue. Your accountant: 'no, you're fired.' Revenue is recognized when EARNED, not when CASH arrives. The other ₦11,000 sits in a liability called Deferred Revenue, you owe the user 11 months of service. Each month you 'earn' ₦1,000 and reclassify it from deferred to recognized.

Cash arriving and revenue being earned are two different events, and a subscription pulls them apart on purpose. The user pays once in January, but they have only bought a promise: twelve months of service you have not delivered yet. Until you deliver each month, that money is not yours to call revenue. It is an obligation, so it lands in a liability account called Deferred Revenue.

Every month you actually run the service, you fulfill one twelfth of the promise and earn one twelfth of the money. So you reclassify ₦1,000 from Deferred Revenue into Subscription Revenue. The bank balance never moves during this, because the cash already arrived in January. What moves is recognition: the slow conversion of an obligation into earned income, twelve times over the year.

This is also why a cancellation is clean instead of catastrophic. The revenue you already recognized stays earned, because you really did deliver those months. Only the unearned portion still sitting in Deferred Revenue gets refunded, and that refund clears both the liability and the cash at once. The split between earned and unearned is sitting right there in the accounts, so you never have to reconstruct it.

Worked example, step by step

User pays ₦12,000 in January

₦12,000 hits your bank. NONE of it is revenue yet. You owe the user 12 months of service, so the entire amount becomes a liability called Deferred Revenue.

Annual subscription payment ₦12,000
AccountDebitCredit
Bank Account (1200)₦12,000.00
Deferred Revenue (2400)₦12,000.00

Bank Account (asset) up ₦12,000. Deferred Revenue (liability) up ₦12,000. Zero revenue. This is the moment most engineers shout 'but they PAID us, that IS revenue!', no. They paid for FUTURE service. Until you deliver each month, you owe.

End of January: recognize one month

January is over. The user got one month of service. You earned ₦1,000 of revenue. Reclassify ₦1,000 from Deferred Revenue (liability) to Subscription Revenue (income).

Recognize January subscription revenue
AccountDebitCredit
Deferred Revenue (2400)₦1,000.00
Subscription Revenue (4000)₦1,000.00

Deferred Revenue DOWN ₦1,000 (debit it, liability decreasing). Subscription Revenue UP ₦1,000 (credit it). Your bank balance does NOT move, cash arrived already. Only the recognition shifts. This entry will repeat every month for a year.

End of February: recognize another month

Same shape. Another ₦1,000 reclassifies from deferred to recognized.

Recognize February subscription revenue
AccountDebitCredit
Deferred Revenue (2400)₦1,000.00
Subscription Revenue (4000)₦1,000.00

Same entry. At year-end, Deferred Revenue will reach ₦0 and Subscription Revenue will total ₦12,000. The cash arrived ONCE; the revenue is recognized TWELVE times.

Takeaway

Revenue is recognized when earned, not when received. For subscriptions, that means amortizing across the service period. Deferred Revenue is a liability, it represents service you OWE. Get this wrong and your financial reports become fiction. No auditor will sign them. No investor will trust them.

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.

More in this section

Search lessons

Type to find any of the 85 lessons. Press Enter to open.