Two numbers, both correct, wildly different
Your dashboard says monthly recurring revenue is 180,000 dollars. Your income statement for the same month says 143,000. Neither is wrong. They are answering different questions, and confusing them is the most common reporting error in software businesses.
MRR is a forward-looking operating metric: the normalised subscription value you expect to bill every month. Recognised revenue is an accounting figure governed by ASC 606: the portion of your contracts you have actually earned by delivering service. A twelve-month contract billed upfront is cash today and MRR today, but it is recognised one twelfth at a time.
Where the gap comes from
Annual prepayments
A customer pays 24,000 dollars in January for a year of service. You have 24,000 in the bank and 2,000 of recognised revenue. The remaining 22,000 is deferred revenue, which is a liability, because you owe eleven more months of service. Treating that cash as earned is how software companies overstate profitability and then run short later in the year.
Mid-term upgrades and downgrades
A customer on a 500 dollar monthly plan upgrades to 900 on the 14th. The billing system may prorate, charge the difference, or roll it into the next invoice. Revenue recognition does not care what billing did: you earned sixteen days at the new rate and fourteen at the old one. If your books take the invoice at face value, every upgrade introduces a small error that compounds across hundreds of customers.
Usage-based and overage charges
Consumption revenue is earned when the consumption happens, not when it is invoiced in arrears. A customer who burns through their allowance on the 28th has generated revenue in that month, even though the overage appears on next month's invoice. Without an accrual, your revenue lands one month late, permanently.
Implementation and onboarding fees
A one-time setup fee is rarely a distinct performance obligation under ASC 606. If the setup has no value to the customer without the subscription, the fee usually spreads across the contract term rather than landing in the month it was charged. Recognising it immediately inflates the month you close a big deal and makes growth look lumpier than it is.
What deferred revenue tells you
Deferred revenue is one of the most useful numbers a software business has, and most treat it as an accounting artefact. It is contracted work you have been paid for and have not yet delivered. A growing deferred balance means you are selling longer or larger commitments. A shrinking one, while MRR looks flat, means you are quietly shifting to shorter terms, which is a leading indicator worth catching early.
Getting it right without drowning in it
The practical setup for most SaaS businesses under roughly 50 million in revenue is this:
- A deferred revenue schedule per contract, rebuilt monthly, that ties to the balance sheet.
- Revenue recognised on a daily-rate basis so mid-term changes land in the right period.
- Usage accrued at month end based on metered consumption, not billing.
- A monthly reconciliation between the billing system and recognised revenue, with variances explained rather than plugged.
- MRR reported alongside recognised revenue, clearly labelled, so nobody confuses them in a board pack.
Why it matters beyond compliance
Anyone doing diligence on a software business will rebuild revenue from contracts. If your recognition has been informal, that rebuild produces different numbers from the ones in your data room, and every number you have reported becomes suspect. Fixing it during diligence costs far more than maintaining it, and it happens at the worst possible moment.
TallyWise provides this as part of our SaaS accounting services. Book a call to talk through your situation.
