Startups Bookkeeping Fractional CFO

Your First Annual Contract Just Broke Your Books: Deferred Revenue for Seed-Stage SaaS

Published October 16, 2026 by Invisible LLC Team · 9 min read

You're a founder, not an accountant. You closed the biggest deal in the company's history — $48,000, annual, paid upfront, wired before the ink dried — and you did the obvious thing: you booked it. September was a monster month.

Then you sent the investor update, and somebody replied with the five words that sent you here: that's not how that works.

Key takeaways: When a customer prepays for twelve months of access, you've been paid for a service you haven't delivered yet. The cash is yours; the revenue isn't — not all at once. The unearned part sits on your balance sheet as a liability and moves onto the income statement as you deliver the year. Nothing is wrong with your business and nothing is wrong with your bank account. What's wrong is the shape of your revenue curve, and the fix is a schedule, not a rebuild.

What actually happened to your revenue chart

Here is deferred revenue in one paragraph, and then we'll never define it again.

You collected a year of money for a year of service. On the day the wire landed you had delivered none of it. So the $48,000 isn't revenue yet — it's an obligation to deliver software for twelve months, and obligations live on the balance sheet. Each month you keep the service running, you've earned a piece of it, and that piece moves from the balance sheet to the income statement. By month twelve the obligation is zero and the revenue is fully recognized. The formal framework is FASB's revenue standard — Accounting Standards Update No. 2014-09, Revenue from Contracts with Customers (Topic 606) — which recognizes revenue as you satisfy the promise you made. For twelve months of continuous access to a product, that works out to even recognition across the twelve months.

One naming note, because it will come up and it trips people: the standard's own term for that balance-sheet obligation is contract liability. Almost everybody labels the line deferred revenue, and the standard permits the alternative description. If your bookkeeper calls it deferred revenue and your investor's accountant calls it a contract liability, they are talking about the same line.

What this does to your chart is the whole reason you noticed. Booked all at once, September shows $48,000 and October shows whatever else closed — a spike and a cliff. Recognized properly, September through next August each show $4,000. Same cash, same contract, same customer. One version makes your growth rate unreadable; the other makes it a line an investor can extrapolate from.

Bookings, billings, revenue — three numbers, one contract

The reason this feels confusing is that your $48,000 deal produces three different legitimate numbers, and most founders have only ever needed one.

Bookings — what the customer committed to. $48,000, on the day they signed. This is the sales number. It tells you about momentum.
Billings — what you invoiced. $48,000, on the day you sent it. This is the cash-flow number. It tells you when money arrives.
Revenue — what you earned. $4,000 in September. This is the accounting number. It tells you what the business actually produced in a period.

All three are true at the same time. None of them is ARR, which is a forward-looking run-rate derived from your contracts — and which is the number that gets wrong first when deferred revenue isn't tracked, because people reach for recognized revenue, multiply it by twelve, and get a figure that has nothing to do with the book of business.

The practical discipline is boring and it works: say which number you mean every time you say a number. "We booked $48K in September" and "we recognized $4K in September" are both honest sentences. "September revenue was $48K" is the one that gets you corrected in a board meeting.

Why "we're cash basis" stopped being true the day you signed

Your bookkeeper is probably not wrong, exactly. Cash basis is a real and legitimate basis of accounting — it just isn't GAAP, and it's structurally incapable of showing what you now need to show.

Worth being precise about what forces the change, because nobody actually sent you a rule:

Your investors. Information rights and covenant language in a preferred stock purchase agreement or side letter routinely require financials prepared in accordance with GAAP. Go read yours; most founders never have.
Your lender, if you have venture debt or a line of credit. Revenue-based covenants computed off books that recognize a year of revenue in one month are not going to produce the answer anyone expects.
An audit or a review, if one ever happens. An auditor opines on conformity with the framework you say you're using. One-month recognition of a twelve-month contract is a misstatement under GAAP, and it's the kind that's trivially easy to find.
Your own metrics. Growth rate, gross margin trend, net revenue retention. All of them are computed on recognized revenue, and all of them are nonsense if the recognition is lumpy.

And one thing that is probably not forcing your hand: the IRS. Tax method and book method are two different questions. The cash method is available to most entities under the gross-receipts test in Internal Revenue Code §448(c) — a threshold of $32,000,000 in average annual gross receipts for tax years beginning in 2026, per Rev. Proc. 2025-32, section .30 (Internal Revenue Bulletin 2025-45, November 3, 2025), with the framework and exclusions laid out in IRS Publication 538. At $48,000 of contract value you are not close. You can legitimately file on the cash method and keep accrual books at the same time — plenty of companies do. So if someone tells you the IRS is why your September was wrong, they've got the wrong reason for the right conclusion.

What a deferred revenue schedule actually looks like

This is the artifact. It is less intimidating than it sounds, and for one contract it fits on a napkin.

A schedule has one row per contract and one column per month. For your $48,000 deal signed September 1 with a twelve-month term:

	Sep	Oct	Nov	…	Aug	Total
Revenue recognized	4,000	4,000	4,000	…	4,000	48,000
Deferred balance, month end	44,000	40,000	36,000	…	0	—

Three things make it real rather than decorative:

It ties to the balance sheet. The sum of every contract's month-end deferred balance equals the deferred revenue account in your general ledger. If it doesn't tie, one of them is wrong, and that reconciliation is the control.
It's driven by the service period, not the invoice date. A contract that starts mid-month gets prorated. A contract that starts in January but was invoiced in November defers for two extra months.
It gets a journal entry every month. Debit deferred revenue, credit revenue, for the amount earned. One entry per month per currency, not per transaction.

For one contract, a spreadsheet is a completely defensible answer and you should not let anyone sell you a system. The spreadsheet stops being defensible somewhere around the point where you have twenty contracts, mid-term upgrades, and a couple of multi-year deals — because then the schedule is where mistakes hide instead of where they're caught.

What Stripe Billing does and doesn't do to your general ledger

This is where most founders in your position lose a month, so it's worth being exact. Your stack is Stripe Billing plus QuickBooks Online, and the gap between them is the thing that produced your September.

Stripe Billing bills. It does not do your accounting. Its documented job is subscriptions, usage tracking, pricing models, invoicing, and retries (Stripe Billing docs). There is no general ledger in it and it posts no journal entries.

Stripe's default reports reconcile cash, not revenue. The standard reporting set is organized around reconciling your Stripe balance — the Balance report is explicitly described as resembling a bank statement, and the dates are the dates money moved (Stripe reports docs). That is the mechanism behind your error. Stripe's out-of-the-box numbers are the cash-basis answer, they're correct as cash answers, and nothing in that report set is trying to recognize revenue.

Revenue Recognition is a separate Stripe product, with its own dashboard and its own docs, offered with a 30-day free trial (Stripe Revenue Recognition docs). Turned on, it maintains deferred revenue and long-term deferred revenue accounts, produces a revenue waterfall, and generates a debits-and-credits report — including a CSV formatted for import into QuickBooks Online, grouped by accounting period and currency (Revenue Recognition reports). Useful. Worth looking at.

Three things about it that are easy to misread, all from Stripe's own documentation:

The QuickBooks hand-off is a manual import of a summarized journal entry, not automatic posting. Stripe computes the entry; a human downloads the CSV, imports it, and owns the mapping from Stripe's accounts to your chart of accounts. Separately, Stripe notes it doesn't support third-party accounting-tool reconciliation of Stripe reports, and the QuickBooks and Xero sync apps in its ecosystem are built by third-party developers, not by Stripe.
It recognizes by the second by default. Monthly recognition — which is what your books want — currently requires asking Stripe support to enable it.
One-time payments reproduce your exact error inside the tool. A charge created outside a subscription has no service period attached, so it's recognized immediately unless you supply one. If your $48,000 came in as a one-off invoice rather than an annual subscription, turning on Revenue Recognition does not by itself fix September.

None of which is a knock on Stripe. It's a billing system doing billing correctly. The point is that no tool in your stack is currently asserting what month your revenue belongs in, which means a person is — and right now that person is you, by accident.

The two places this gets genuinely hard

The twelve-months-of-access case is the uncontested one, and if that's all you have, you have a bookkeeping task rather than a judgment problem. Two adjacent fact patterns are genuinely contested, and you should treat them as questions for your accountant rather than things to settle from a blog post.

Nonrefundable setup or implementation fees. If you charged $5,000 to onboard that customer, the analysis is not obvious: whether the fee relates to a distinct service you actually transferred, and if not, over what period the advance payment should be recognized — the contract term, or something longer if a renewal option gives the customer a material right. FASB's own staff published a dedicated implementation Q&A on precisely this question, which is the cleanest available evidence that practitioners don't agree on it.

Usage-based overage. Variable consideration has to be estimated and then constrained — included only to the extent a significant revenue reversal isn't expected when the uncertainty resolves. Two stacked estimates with a probability threshold on top is judgment by construction. Worth knowing: Stripe doesn't attempt this. Its documentation states that usage-based revenue is recognized in full when invoices finalize or the period closes, which is a defensible simplification and is not the same thing as the standard's answer.

If either of those is in your contracts, the honest advice is to get it decided once, in writing, by someone who will stand behind it — and then apply it consistently. The consistency matters more than the choice.

What to do this week — and where we fit

The short version of the fix: find every contract where you've been paid for service you haven't delivered, build the schedule, book the catch-up entry, and then do one journal entry a month. For a company your size that is a day of work and then fifteen minutes a month. It is not a migration, it is not a system change, and it does not require moving off QuickBooks.

Then, before your next raise, read our pre-raise diligence checklist — revenue cut-off and missing deferred revenue are the two most common findings in founder-kept books, and you've just met both of them. When finance stops being a monthly entry and starts being a reconciliation somebody has to own, that's the outsourced controller layer, and it's the next thing you'll buy, probably around the time a board member asks you to defend a net-revenue-retention number.

Where we fit: we're the bookkeeping layer with revenue recognition built into it rather than bolted on afterward — the bookkeeper who already assumes your deferred revenue is wrong and asks for the contracts on day one, in the stack you already have. We work with founders and startups and we are deliberately not trying to be more than that at your stage. Where we don't fit, plainly: we don't perform audits and we don't issue assurance of any kind; we're not the firm to implement an enterprise ERP; and if you're past a Series A with a finance lead in-house, you've outgrown our altitude and we'd rather say so on the first call.

Tell us what your contracts look like and we'll tell you whether this is a one-day fix or something bigger. If it's a one-day fix, we'll say that too.