Bookings vs Revenue

Bookings vs revenue: at a glance

‍

Bookings measure the total value of signed customer contracts before any delivery or payment. Revenue is recognized under ASC 606, as each performance obligation is satisfied. ^[1] The same contract therefore produces different numbers in your CRM system, your billing system, and your income statement. Bookings tell your board what sales committed this quarter, while revenue tells your auditors what you earned.

‍

Take a $120K annual contract signed in January, billed quarterly, with service starting on February 1st. One month into service, that single contract is producing four different correct numbers: a $120K booking, a $30K first invoice, $10K of monthly recognized revenue, and a $110K RPO balance — of which only $20K sits in deferred revenue. All four are right. The trouble starts when someone treats one of them as “the” number, or when two teams pull different ones into the same conversation.

‍

To untangle the confusion, this guide covers what each metric measures and the journal entries that move a contract from one to the next. We’ll also look at the governance layer that finance teams often forget to document.

Bookings vs billings vs revenue vs ARR: an overview

What are bookings?

Bookings aren’t defined by GAAP — they’re an internal operating metric, owned by sales rather than accounting. They capture committed contract value at the moment a customer signs, and they live in CRM, never touching the general ledger.

‍

Worth flagging early, because it trips people up later: “not GAAP” does not make bookings a “non-GAAP financial measure” in the SEC’s sense. That term is narrower than it sounds — it means a measure derived by adjusting a GAAP figure. Bookings is built from contract data that never touches the financial statements, which puts it in a different regulatory box entirely.^{[2], [3], [4]} More on that below.

‍

Finance teams tend to track several flavors at once:

‍

• New bookings: Contract value from customers who weren’t customers before
• Expansion bookings: Incremental committed value from existing customers (seats, tiers, modules…)
• Renewal bookings: Contract value from customers re-committing at the end of a term
• Total bookings: All the above, combined

‍

Whether renewals belong in your headline bookings number is up to you: it’s a policy choice, not an accounting rule. Two companies with identical sales performance can report very different bookings numbers, simply because they define the term differently.

‍

Contract length raises another common question: TCV (total contract value) or ACV (annual contract value)? A three-year deal at $100K a year is $300K of TCV and $100K of ACV. Both numbers are defensible, but only one is comparable quarter to quarter (and then only if you use the same one consistently). If you switch to TCV in a quarter with an unusual multi-year deal, your growth rate will reflect contract length rather than real demand.

‍

Sales pipeline isn’t bookings, either. Commitment requires a signature — a verbal “yes” doesn’t count. And a booking with no billing schedule attached is still just a forecast as far as cash is concerned. It counts toward contracted backlog, but nothing hits the ledger until you deliver or payment comes due. ^[1]

What is revenue?

Revenue is contract value earned by satisfying performance obligations, governed by ASC 606’s five-step model. ^[1] Unlike bookings and billings, revenue appears on your income statement and in your audits.

‍

A reminder of ASC 606’s five steps:

‍

1. Identify the contract with the customer
2. Identify the performance obligations (the goods or services promised)
3. Determine the transaction price
4. Allocate the price across the obligations
5. Recognize revenue as each obligation is satisfied

‍

For a deep dive, check out our guide to ASC 606 revenue recognition.

‍

Timing depends on how the obligation is satisfied. A SaaS subscription is satisfied continuously over the term, so it’s recognized over time, month by month. A perpetual license is different: software is what ASC 606 calls functional intellectual property, so once you’ve delivered a copy and the customer’s usage period has begun, control has transferred and the amount allocated to that license is recognized at a point in time. ^[5]

‍

Two caveats on that, because both catch people out. The clock starts with delivery and the start of the license period, not with signature — revenue can’t be recognized before both have happened. And if you’re obliged to ship updates that substantively change the software and the customer has to take them, recognition reverts to over time (ASC 606-10-55-58C; 606-10-55-62). ^[5]

‍

Because of this, taking shortcuts — saying “we’ll recognize it when they pay” — doesn’t work under accrual accounting. Cash timing and delivery timing are independent. A customer who prepays 12 months in January hasn’t actually given you 12 months of revenue in January, so recording it that way will overstate the income statement and understate the deferred revenue liability — and both get caught quickly in VC diligence or an audit.

The bookings-to-revenue waterfall

A booking becomes revenue by passing through invoicing and deferred revenue. Each step is a separate event with its own audit trail. The booking itself creates no journal entry: under ASC 606’s presentation guidance, a contract asset or contract liability arises only once one party performs or consideration becomes due, so a signed but unbilled and undelivered contract produces nothing in the ledger.^[1] Upfront billings create deferred revenue — a contract liability, in ASC 606’s language — on the balance sheet. Deferred revenue converts into recognized revenue as the service is delivered month by month.

12-month waterfall: one $120K contract across four ledgers

This example is for a contract signed on January 15th. Service runs from February 1st to January 31st. The contract’s billed quarterly, in advance.

‍

‍

One note on that last row: the deferred revenue figure is the closing balance at December 31, not the sum of the column. Deferred revenue is a balance that rises and falls all year — adding it up doesn’t mean anything.

The three journal entries: booking, billing, recognition

‍

In January, sales reports a $120K booking and the general ledger reports nothing (no invoice = no delivery = no entry). Although both numbers are right, there’s a big gap between them: we see $120,000 in the board deck and $0 on the income statement.

‍

In February, the first invoice arrives. It creates a $30,000 receivable and a $30,000 deferred revenue liability. Still no revenue. Then service begins, and the first $10,000 is earned: deferred revenue moves to revenue. Deferred revenue closes February at $20,000.

‍

In March, there’s no booking and no invoice. Another $10,000 is recognized, bringing deferred revenue down to $10,000.

‍

The same pattern repeats for the rest of the year: $10,000 of revenue is recognized every month, deferred revenue rises with each new invoice and falls as revenue is recognized, and bookings don’t move for the rest of the year.

‍

By December 31, the customer has been invoiced the full $120,000 and you’ve earned $110,000 of it. The remaining $10,000 stays in deferred revenue until it’s recognized in January.

What happens if the customer leaves halfway through

Now say the customer leaves at the halfway mark. Before touching the numbers, be precise about what actually happened — this is where the shortcuts start.

‍

If they simply stopped logging in, nothing changes. A SaaS subscription is a stand-ready obligation: you’re still holding the service available, so you keep recognizing revenue over the contract term regardless of usage. ^[6] Non-use is a retention problem, not an accounting event.

‍

If the contract is actually terminated, the picture moves. Bookings still don’t change — the $120,000 January booking already happened, so it stays on the books. Revenue stops at the termination date, because the parties’ enforceable rights and obligations have ended. ^[1] Say they terminate at the end of June, five months into service: you’ve recognized $50,000, and the uninvoiced remainder of the term drops out of your RPO.

‍

That leaves the $10,000 you’ve already invoiced but not yet earned. It goes one of two ways. If it’s refundable, you refund it. If the contract makes it non-refundable and your obligation is extinguished, it gets recognized as revenue — in proportion to the pattern of rights exercised where you expect to be entitled to it, otherwise once the likelihood of the customer using its remaining rights becomes remote (ASC 606-10-55-46 to 55-49).^[1] What you cannot do is write it off. A contract liability doesn’t simply disappear, and “we wrote off the deferred balance” is the kind of entry an auditor reverses.

RPO: the audited version of bookings

RPO is the ASC 606 disclosure of contracted revenue you haven’t recognized yet (ASC 606-10-50-13) — the transaction price sitting against performance obligations you still owe. ^[1] It’s a footnote in the audited annual financials, not a slide in the board deck. It’s also how the market reads “bookings” once a company reports publicly: the same commitment, but reviewed by auditors and filed with the SEC.

‍

Two carve-outs worth knowing before you assume it applies to you. Private companies can elect out of the RPO disclosures entirely (ASC 606-10-50-16). ^[1] And any company can skip performance obligations under contracts with an original expected duration of a year or less — though if you use that expedient, or the related ones for variable consideration, you have to say so (ASC 606-10-50-14 through 50-15). ^{[1], [8]} Between them, those exemptions cover a lot of annual-contract SaaS.

‍

Public SaaS companies report RPO because ASC 606 requires it, and most also break out cRPO (current RPO, the portion expected to convert to revenue in the next 12 months).^{[1], [9]} Bookings can still show up in public communications, but as a management-defined metric outside the financial statements — a materially weaker perch: no standard definition, no auditor opinion, and an SEC expectation that you spell out exactly how you calculate it.

‍

Internal bookings roughly become RPO additions, but the two won’t tie out exactly, and it’s worth knowing why. RPO runs only as far as the parties have present enforceable rights and obligations (ASC 606-10-25-3), so anything a customer can walk away from without a substantive termination penalty sits outside it. ^{[1], [7]} Where the penalty is substantive, the enforceable term — and therefore RPO — extends across the whole penalty period. Add your own bookings convention on top (TCV may span years RPO doesn’t) and the disclosure exemptions above, and you have three separate reasons the two numbers differ. Note that billing timing isn’t one of them: RPO covers billed and unbilled alike,^[9] so invoicing earlier or later only shifts the split between deferred revenue and unbilled RPO.

‍

That said, bookings discipline is still important if you plan to go public. In our experience, if your CRM bookings can’t be reconciled to your contract records now, you’ll be rebuilding that history — on a tight deadline, needless to say — during S-1 prep. The gap between tracking bookings and being able to disclose RPO is both a definitions problem and a data problem, and neither is a quick fix.

‍

RPO and deferred revenue overlap, and CFOs blur them constantly. Deferred revenue is billed-but-unearned only. RPO is broader, including contracted value you haven’t billed yet. In the $120K example above, February’s RPO is $110,000 (everything still to be delivered), while deferred revenue is $20,000 (only what’s been invoiced).

Define your bookings policy now — before due diligence writes it for you

Take a composite we’ve seen more than once. A founder tells the board they’ve booked $9M. The data room shows $330K a month in recognized revenue — under $4M annualized. Nobody’s lying: the $9M is total contract value across multi-year deals, a chunk of it hasn’t gone live yet, and the board heard a number no one had ever defined. A written bookings policy removes the definitional ambiguity behind most disputes like this, in board reporting, audits, and due diligence alike.

The 7 policy decisions every CFO needs to lock in

‍

Consistency beats cleverness here. Choose your definitions once, apply them every quarter, and disclose any changes.

‍

Note also that these points don’t always stay internal. Once you’re a registrant, bookings is treated as a key performance indicator rather than a non-GAAP financial measure ^[4] — the SEC’s 2020 MD&A guidance expects you to define the metric clearly, explain why it’s useful to investors, say how management actually uses it, and disclose the assumptions behind it. ^[10] The definitional discipline you build now is the disclosure you’ll owe later.

‍

One boundary worth marking, because it’s where the two regimes meet: bookings escapes the non-GAAP rules only because it starts outside the financial statements. The moment a metric starts from a GAAP number, it crosses over. “Calculated billings” — revenue plus the change in deferred revenue — does exactly that, which is why public SaaS companies present it as a non-GAAP measure and reconcile it to revenue. ^{[2], [3], [11]} The same logic catches an “RPO including cancellable amounts” figure: it adds back amounts the GAAP-required RPO disclosure excludes, which is exactly what Regulation G’s definition of a non-GAAP financial measure describes. ^{[2], [3]} (TCV, by contrast, sits in the same box as bookings — it is contract data that never touches the financial statements.)

What bookings-revenue divergence tells you

Don’t panic if you see a widening gap between bookings and recognized revenue — it’s simply a sign that something needs a second look. Depending on which intermediate metric stalls, it usually points to implementation, billing, collections, or churn.

Explaining the gap

‍

Book-to-bill is a useful first check, borrowed from hardware: divide bookings by billings for the same period. Sustained above 1.0, you’re signing faster than you’re invoicing and your billable backlog is growing. Persistently below 1.0, you’re using up that backlog faster than you’re replacing it.

‍

The catch is that it only works if you measure both sides the same way. Book TCV against quarterly billings and the ratio sits above 1.0 no matter what demand does — run the $120K contract above and Q1 comes out at $120,000 ÷ $30,000 = 4.0. Compare like with like (ACV bookings against annualized billings), then read the trend rather than the level.

‍

One variable that’s widely under-monitored at enterprise scale is time-to-live — specifically, the lag between signature and the start of service. A $120K contract that goes live 90 days late doesn’t reduce bookings at all. It moves $30,000 of revenue into next year — or loses it outright, if the contract’s end date doesn’t move with its start date — even though the board still sees the deal as a win.

Why the tie-out is the biggest problem — and how software can help

Bookings live in the CRM. Billings live in the billing tool. Revenue lives in the GL. Three systems, three owners — and one board asking why the numbers disagree. Definitions cause the arguments; reconciliation causes the hours.

‍

Everyone who’s worked in finance knows the routine. Export the CRM bookings report, export the billing schedule, pull the revenue subledger… and then spend days figuring out why they don’t line up. The discrepancies almost always come down to the same things: contract amendments that updated the CRM but not the billing schedule, mid-term upgrades that need reallocation across performance obligations, and co-term deals where two contracts were merged into one end date but the ledger wasn’t updated.

‍

That middle one is worth naming properly, because it’s a rule and not just an annoyance. A mid-term upgrade is a contract modification under ASC 606, and the standard dictates whether you treat it as a separate contract, a termination and new contract, or a cumulative catch-up adjustment (ASC 606-10-25-10 through 25-13). ^[1] Get that judgment wrong in the CRM and the ledger inherits it.

‍

These data-lineage problems happen again and again, every close, because the contract exists in three places, each with a different version of the truth.

‍

Fixing it starts with one contract record driving everything downstream. The CRM booking, billing schedule, deferred-revenue amortization, and RPO disclosure, all pulled from the same source and updated automatically in case of contract modifications. DualEntry automates the bookings-to-revenue tie-out by unifying contract, billing, and GL data in one AI-native ERP.

Closing thoughts

The meaning of “bookings” gets argued about at the seed stage and gets written down by Series B. By the time you’re public, RPO and an auditor do that job for you. Regardless of your stage, handling reconciliation manually — three systems, one contract, and someone deciding by hand whether the numbers agree — is what can slow you down the most.

‍

Schedule a demo to see how DualEntry automates revenue recognition, taking the tie-out off your finance team’s plate for good.

Bookings vs Revenue FAQs