Deferred Revenue

Why money in the bank can be a liability

The instinct is that cash received is revenue earned. Accrual accounting separates the two, and deferred revenue is where they come apart most visibly.

Charge a customer $1,200 in January for twelve months of service and you have $1,200 in the bank on 2 January. You have earned almost none of it. You owe eleven and a half months of service to somebody who has already paid, and if you shut down in March you would owe most of it back. That obligation is the liability.

So the January entry credits a liability account rather than an income account, and revenue is recognized as the service is delivered, typically $100 a month. By December the liability has drained to zero and the income statement has recorded $1,200 spread across the year it was actually earned in.

Book it all as January income instead and two things break at once. January looks like an extraordinary month, and the following eleven look like a collapse. Any margin, growth, or run-rate figure calculated from those months is measuring your billing calendar rather than your business.

The mirror image of accounts receivable

Deferred revenue is easiest to hold onto when you see it next to its opposite.

[Accounts receivable](/glossary/accounts-receivable) is revenue you have earned but not yet collected. You did the work, you invoiced for it, the cash has not arrived. It is an asset, because somebody owes you money.

Deferred revenue is the reverse: cash you have collected but not yet earned. The money arrived first, the work comes later. It is a liability, because you owe somebody service.

Both exist for the same reason. Cash and delivery happen on different dates, and accrual accounting insists that revenue is reported when it is earned rather than when it moves. One account holds the timing difference in each direction.

Which one a Stripe business ends up with depends on how it bills. Invoice on net terms and you build receivables. Charge up front for a period of service, which is what most subscription pricing does, and you build deferred revenue. Plenty of businesses run both at once.

What Stripe shows you, and what it does not

Stripe reports cash movement. That is the correct job for a payment processor, and it is worth being clear about where its reporting stops.

A $1,200 annual plan charged on 2 January appears in Stripe once, in January, at full value. Stripe has no opinion about which months that money belongs to, because from its point of view nothing further happens: one charge, one amount, one date. The same is true of the payout that carries it to your bank.

Anything that mirrors Stripe faithfully inherits that shape. A sync that records the January charge accurately has done its job correctly and has still given you a January-weighted revenue picture, because that is what the underlying transaction looks like.

The schedule that turns one payment into twelve months of revenue lives in QuickBooks, and somebody has to build it. In practice that means a deferred revenue liability account in your chart of accounts, and a recurring [journal entry](/glossary/quickbooks-journal-entry) that moves an agreed amount from that account into income each period. Both are accounting policy decisions rather than data problems, which is exactly why no integration makes them for you.

If you need full ASC 606 revenue recognition with automated schedules, that is a dedicated revenue recognition system, layered on top of accurate books rather than replacing them.