GTM Algorithm/Blog/RevOps
Bookings vs.ARRGTM ALGORITHMREVOPS
REVOPS · 9 MIN READ

Bookings, billings, revenue, ARR: why sales and finance never agree

Sales reports bookings, billing reports invoices, finance reports recognized revenue and the board asks for ARR. All four are right, and they never match. One deal walked through all four numbers, and three weekly checks that catch the real mismatches between your CRM and billing.

Arvind Reddy
Arvind ReddyLinkedIn ↗
GTM Lead ·
In this article 8 sections
  1. Four numbers, four owners
  2. One deal, four numbers
  3. Why revenue always lags: ASC 606 in plain English
  4. Where the CRM and billing actually drift
  5. Three checks between the CRM and billing
  6. One owner and one definition per metric
  7. The bottom line
  8. Sources

It is the end of the quarter. Sales says it closed $1.2M. Finance says revenue was $800K. The CEO asks why the board deck says ARR grew by a number that matches neither. Somebody says "we need a single source of truth," everyone nods, and the same conversation happens again next quarter.

The uncomfortable truth is that all of those numbers can be correct at once. Bookings, billings, revenue and ARR measure different things, at different moments, for different audiences. The real problem is not that they differ. It is that nobody has written down how they differ, so every gap looks like an error, and the actual errors hide among the expected gaps.

This article walks one hypothetical deal through all four numbers, explains why recognized revenue always lags, and gives you three weekly checks that catch the mismatches that do cost money.

Four numbers, four owners

MetricWhat it measuresWhen it countsUsually reported by
BookingsThe value of a signed contractAt signatureSales
BillingsWhat you invoicedOn the invoice dateBilling or accounts receivable
RevenueWhat you have earned by delivering the serviceAs the service is deliveredFinance
ARRThe annualized value of recurring subscriptionsAt a point in timeLeadership and the board

The cleanest short definitions come from a16z's well-known guide to startup metrics. "A common mistake is to use bookings and revenue interchangeably, but they aren't the same thing." Bookings are "the value of a contract between the company and the customer." Revenue is recognized "when the service is actually provided or ratably over the life of the subscription agreement." And ARR "should exclude one-time (non-recurring) fees and professional service fees" (a16z).

One warning on vocabulary: some sources use "ARR" to mean annualized run rate, which multiplies a recent period's revenue up to a year (Stripe). That is a different number. Decide which one your company means and write it down.

One deal, four numbers

Here is a hypothetical deal, chosen to be ordinary rather than extreme:

  • A two-year subscription contract, signed on 1 January
  • $60,000 for year one and $90,000 for year two (a ramp, as the customer rolls out to more teams)
  • A one-time $10,000 setup fee
  • Billed annually in advance
One deal, four correct numbers
One deal, four correct numbersSame contract, four different numbers in year one. None of them is wrong; they answer different questions.

Bookings: $160,000. The total contract value, counted the day it is signed: $60,000 + $90,000 + $10,000. Some teams book only the first year or only the annual value. Whatever you choose, it is a definition, not a fact, so write it down.

Billings: $70,000 in year one. The first invoice covers the setup fee and year one. The year-two invoice of $90,000 goes out a year later.

Revenue: $65,000 in year one. The subscription is earned evenly as the service is delivered: $15,000 a quarter in year one. The setup fee is the tricky part. In this example, finance treats it as part of the subscription rather than a separate deliverable, so it is spread over the two-year contract at $5,000 a year. Your finance team and auditors make that call, not RevOps.

ARR: $60,000, then $90,000. Recurring subscription value only, with no setup fee. It steps up when year two begins. (Some companies also track contracted ARR, which counts the year-two step-up as soon as it is signed. Again: pick one and write it down.)

Now look at the same deal by quarter.

Same deal by quarter: cash lumps, revenue spreads
Same deal by quarter: cash lumps, revenue spreadsBillings arrive in two lumps. Revenue arrives in eight even slices. Both add up to $160,000 over two years, yet they never match in any single quarter.

If sales compares its bookings to finance's quarterly revenue, it will look like 90% of the deal went missing. It didn't. It just hasn't been earned yet.

Why revenue always lags: ASC 606 in plain English

Under US GAAP, revenue recognition follows ASC 606, which has five steps (BDO):

  1. Identify the contract with the customer.
  2. Identify the performance obligations: the separate things you promised to deliver.
  3. Determine the transaction price: what you expect to receive, after discounts and credits.
  4. Allocate the price across the performance obligations.
  5. Recognize revenue when (or as) each obligation is satisfied.

The core principle is that revenue reflects the transfer of what you promised to the customer, in the amount you expect to be paid for it (BDO). A subscription is delivered day by day, so it is recognized day by day. That is why revenue trails bookings by design.

Steps 2 to 4 are also where sales and finance most often disagree, because they depend on deal details that live in the CRM: discounts, free months, bundled services, ramps and non-standard terms. If those details are missing or wrong in the CRM, finance has to chase them, and the numbers drift.

Where the CRM and billing actually drift

Expected differences, like the ones above, are fine once everyone understands them. The ones that cost money are the unexpected differences between what sales closed and what billing actually charges. They usually fall into a handful of patterns:

  • Closed-won, never invoiced. The deal was marked won, but no subscription was ever created in billing. Nobody notices until renewal, or never.
  • Amount or term mismatch. The CRM says 50 seats at a 15% discount for two years. Billing says 40 seats, no discount, one year.
  • Wrong start date. Billing started a month late, or before the service was live, so revenue and cash both shift.
  • Services counted as recurring. A one-time implementation fee ends up in ARR and inflates it.
  • Changes that never reached the CRM. Upgrades, downgrades and credits handled in billing alone, so the CRM's view of the customer is wrong.

What drift costs

Analyst estimates of "revenue leakage," money a company earned but never collected, are sobering. MGI Research estimates it represents "at least three to five percent of every company's revenue" (MGI Research). That is an analyst estimate across industries rather than a measured figure for SaaS, and the full report is paywalled, but even the low end of that range is real money.

Confidence in the numbers is weak too. In a Gartner survey of sales operations, only 45% of sales leaders and sellers had high confidence in their organization's forecast accuracy, and only 47% believed their organization had high-quality data (Gartner). That survey is from 2020, but few teams would claim it has gotten easier since.

Three checks between the CRM and billing

You don't need a new system to catch most of this. You need three comparisons, run every week, with one person who owns the exceptions.

Three checks between the CRM and billing
Three checks between the CRM and billingCompare closed-won deals with subscriptions and invoices on three fields. Anything that doesn't match goes on one list with one owner.

Check 1: Missing. Every closed-won deal in the last 90 days should have a matching subscription or invoice. List every deal that doesn't.

Check 2: Mismatched. For every matched pair, compare price, quantity, discount and term. Flag any difference above a small tolerance.

Check 3: Mistimed. Compare the contract start date in the CRM with the billing start date. Flag any gap of more than a few days.

The output is a single weekly exception list: deal, what doesn't match, and who owns the fix. Most weeks it will be short. The weeks it isn't are the ones that would have cost you.

Building it

You can run this in a spreadsheet to start: export closed-won deals and active subscriptions, join them on a shared customer ID, and compare the three fields. To automate it, a workflow tool such as n8n can pull both lists on a schedule, run the comparisons and post the exceptions to a channel. The hard part is not the tooling. It is having a shared customer ID in both systems, so records can be matched without guesswork. If you don't have one, that is your first project.

One owner and one definition per metric

The reconciliation catches errors. Definitions stop the arguments. Write a one-page metrics glossary that answers, for each of the four numbers:

  • The definition, in one sentence, including what is in and what is out (setup fees, services, discounts, ramps).
  • The system of record: CRM, billing system or general ledger.
  • The owner: the one person who can say what the number is.
  • The cadence: when it is final each month or quarter.
  • The bridge: how it relates to the others. "Bookings minus multi-year amounts not yet billed equals billings" is the kind of line that ends a meeting early.

Then use the glossary everywhere: the board deck, the forecast call and the CRM dashboards. When someone asks why sales' number doesn't match finance's, the answer is a link, not a debate.

The bottom line

Sales and finance aren't disagreeing because one of them is wrong. They are reporting different, correct numbers without a shared explanation of how they connect. Write the four definitions down, give each one an owner, and run three simple checks between the CRM and billing every week. The expected gaps stop causing arguments, and the unexpected ones get caught while they are still small.

Sources

THE GTM ALGORITHM NEWSLETTER

The go-to-market newsletter for GTM leaders. Every Tuesday and Friday.

Unsubscribe anytime

Keep reading

Websitevisitor IDGTM ALGORITHMDATA

Website visitor ID: who's on your site is not a lead (here's what to do instead)

9 MIN · OCT 23→
CRM foragentsGTM ALGORITHMREVOPS

Your CRM is why your AI agents fail

9 MIN · OCT 16→
Deliverability2026GTM ALGORITHMDELIVERABILITY

Gmail and Outlook now reject bad cold email. The 2026 deliverability checklist

9 MIN · OCT 09→