ARR vs bookings vs revenue: stop miscounting

A founder I worked with walked into a board meeting last year with a slide that said $4.2M ARR. His VP Sales had sent a Slack message that morning celebrating $5.1M closed in the year. His accountant's P&L showed $3.1M in revenue.

Three numbers. Same twelve months. Same company. Nobody was lying.

The board chair asked which one was right, and the room went quiet for about four seconds. That silence costs more than most founders realise. It is the moment an investor stops evaluating your business and starts evaluating whether your numbers can be trusted at all.

I have seen this play out at maybe a dozen companies now, almost always between $2M and $15M in revenue. The pattern is identical every time. Nobody wrote down what each number means, so sales counts one thing, finance counts another, and the board deck counts a third. Then someone runs a diligence process and all three get restated.

This post is about fixing that before it becomes expensive.

The three numbers, in plain terms

Most people can recite the textbook definitions. Very few teams apply them consistently, which is the actual problem.

Bookings

Bookings are what you signed. A contract gets countersigned, and the total contract value goes into bookings on that date. If a customer signs a two-year deal at $60K per year with a $20K implementation fee, that is $140K of bookings the day the ink dries.

Bookings are a sales number. They measure commercial execution in the period. They tell you nothing about cash, and nothing about what you will still be earning in eighteen months.

ARR

ARR is the annualised value of subscriptions that are currently active and recurring. Same deal as above: the ARR is $60K, not $140K. The implementation fee is not recurring, and the second year is not active yet.

ARR is a run-rate number. It answers one question: if we froze the company today and nothing changed, what would we earn over the next twelve months from contracts that are live right now?

Recognized revenue

Recognized revenue is what accounting rules let you record as earned. Under ASC 606 you recognise revenue as you deliver the service, so a $60K annual subscription that starts on 1 October gives you $15K of revenue in that calendar year and $45K in the next.

This is the only one of the three with an external rulebook. It is also the one your auditor, your lender, and any acquirer will start from.

Same contract. Three legitimate numbers that differ by almost 10x. This is normal and fine. It stops being fine when nobody in the company can explain the bridge between them.

Where the gap actually comes from

In every audit I have run, the divergence traces back to the same handful of decisions that were never made deliberately. They just happened, usually because someone needed a number for a deck on a Tuesday.

Contracted but not live. A deal closes in March, the customer does not get provisioned until June. Sales counted the ARR in March. Finance recognises nothing until June. Both are defensible. Pick one for the board deck and label it.

One-time fees counted as recurring. Implementation, migration, training, custom build work. This is the single most common inflation source I find. One SaaS CFO guide notes that if more than 15% of your revenue comes from non-recurring implementation fees but is being counted as recurring, you should expect a real valuation haircut in diligence. I have seen worse ratios than that at Series A.

Discounts booked at list price. A team offers 25% off in year one to win a competitive deal, then books the ARR at list and treats the discount as a separate concession that nobody tracks. First-year revenue is overstated for every deal that closed that way. When a quality-of-earnings team finds this, they restate the whole cohort.

Multi-year deals annualised wrong. A three-year contract at $180K total is $60K of ARR, not $180K. Sounds obvious. I have opened CRMs where the deal amount field held total contract value and the ARR dashboard summed that field.

Pilots annualised as if permanent. A three-month paid pilot at $5K per month becomes $60K of ARR on somebody's spreadsheet. It should not. A pilot is not a commitment, and annualising it is how a $4M ARR company discovers it is a $3.2M ARR company two weeks before a term sheet.

The part founders underestimate

Investors reconcile ARR to GAAP revenue. It is a standard step in diligence, not an unusual one, and it is one of the first places inconsistency shows up.

Here is what makes it painful. The reconciliation itself is not the problem. Every SaaS business has a gap between contracted ARR and recognised revenue, and a good investor expects one. What kills deals is being unable to explain the gap. If you can walk through it line by line, the conversation takes twenty minutes. If your CFO has to go build the bridge from scratch during diligence, you have just told the buyer that your reporting is improvised, and they will discount everything else you showed them.

There is no universal ARR standard. Various groups have tried to write one and none has stuck, which means the definition is yours to make. That is an advantage if you write it down and a liability if you do not.

Write the definitions document

This takes an afternoon and it is the highest-return hour of RevOps work available to a company under $20M. One page, shared, dated, and versioned.

For each metric, answer these questions in writing:

• What triggers it? Signature date, subscription start date, or first invoice?
• What is included? Recurring subscription only, or does it include committed usage and support retainers?
• What is excluded? Implementation, professional services, hardware, pass-through costs, one-off training.
• How are multi-year deals handled? Annualised, or counted at total contract value?
• How are pilots and POCs handled? My default is that they never enter ARR until they convert to a standard contract.
• How is usage-based revenue handled? If you sell on consumption, you need a rule for what counts as committed. Usage-based pricing breaks naive ARR maths faster than anything else.
• What currency and FX rate? Spot at close, or a fixed plan rate for the year?
• Who owns the number, and who can change the definition?

That last one matters more than it looks. Definitions drift when three people can quietly edit them. Give one person the pen, usually the head of RevOps or whoever owns the CRM, and make changes visible.

Instrumenting this in HubSpot

Most teams I work with are on HubSpot, so here is the concrete build. The same logic maps to Salesforce or Attio with different field names.

The core mistake is trying to make one deal amount field serve three purposes. It cannot. HubSpot was built to manage pipeline, and the deal amount represents the value you expect to win, not the revenue you will earn over time.

Split it properly:

1. Use line items with a recurring billing frequency for subscription components, and set them to the correct term. HubSpot will calculate annual recurring revenue on the line item natively when the billing frequency is set.
2. Put one-time charges on separate line items flagged as one-time. Never fold them into the subscription line.
3. Add three deal-level properties: ARR, total contract value, and one-time fees. Populate ARR and one-time fees from line item rollups with a workflow or a calculated property so nobody types them by hand.
4. Add subscription start date and subscription end date as required fields on the closed-won stage. Without these you cannot build a revenue schedule, and without a revenue schedule you cannot reconcile to finance.
5. Add a go-live date, separate from subscription start. For anything with an implementation period, these differ, and the difference is exactly the contracted-not-live gap.
6. Build two ARR reports, not one. Contracted ARR uses signature date. Live ARR uses go-live date. Show both on the sales dashboard and label them clearly.

Make the fields required at stage transition, not optional. Optional fields do not get filled, and a nullable ARR field is how you end up with a dashboard that quietly undercounts by 12%. If you have not audited your field hygiene recently, CRM data quality is the prerequisite for all of this.

Step three is the one people skip. Restating history is tedious and there is no prize for it. Do it anyway. A definitions change without a backfill produces a discontinuity in your growth chart that you will spend the next two years explaining.

The monthly bridge

Once the data model is right, the reconciliation is a report, not a project. Run it on the same day each month, right after the books close.

Start with opening ARR. Add new ARR from deals that went live in the period. Add expansion. Subtract contraction and churn. That gives closing ARR, which should tie exactly to your live ARR report.

Then bridge ARR to revenue. Take closing ARR, divide by twelve for a monthly run rate, adjust for mid-month starts, add non-recurring revenue recognised in the period, and compare against the P&L. The gap should be explainable in three or four lines.

If your gap moves more than a couple of percent month over month without a clear cause, something in the data model broke. Usually it is a rep who filled a field wrong, or a workflow that stopped firing. Finding it in a monthly review takes ten minutes. Finding it during diligence takes three weeks and weakens your negotiating position.

This is the same discipline that makes sales forecasting trustworthy, and it feeds directly into net revenue retention, because you cannot measure retention on a base you have not defined.

What I would fix first

If you only have a week, do these two things.

Pull every closed-won deal from the last four quarters into a spreadsheet with the deal amount, the contract term, and whether it included implementation. Calculate true ARR by hand. Compare it to whatever number is in your board deck. In most audits I run, the number moves by 8% to 20%, and it almost always moves down.

Then write the definitions page. Not a policy document, just a page. Send it to your CFO and your VP Sales and make them argue about it in writing until they agree. The argument is the valuable part. Whatever they disagree about is exactly where your reporting has been quietly broken.

The rest of the build, line items, required fields, the monthly bridge, is a few weeks of CRM and RevOps work. It is not glamorous and no rep will thank you. But it is the difference between a board meeting where you present numbers and a board meeting where you defend them.

FAQ

Should the board deck show ARR or revenue?

Both, on the same slide, with the bridge between them. ARR alone invites the question of why it does not match the P&L. Revenue alone hides the run rate, which is what a growth investor is actually buying. Showing both preempts the awkward question and signals that you understand your own business.

Do I count a deal as ARR on the signature date or the go-live date?

Track both, report on go-live. Contracted ARR is a useful sales metric and belongs on the sales dashboard. Live ARR is what ties to revenue and belongs in the board deck. If you only maintain one, maintain live ARR, because that is the one an investor will reconcile against your financials.

How should professional services revenue be treated?

Keep it out of ARR entirely and report it as a separate line. Services revenue is real revenue and there is nothing wrong with having it. The mistake is blending it into a recurring number, because it carries a different margin profile and a much lower valuation multiple. Investors will strip it out anyway. Do it first and get credit for the rigour.

What about usage-based or consumption pricing?

Count only the committed minimum as ARR, and report actual consumption separately as a variable revenue line. Annualising a good month of usage is one of the fastest ways to build an ARR number that collapses in a bad quarter. Some teams also track a committed ARR figure alongside a trailing twelve-month consumption figure, which gives the board both the floor and the reality.

How often should I restate historical numbers?

Only when the definition changes, and then all at once. Restate the full history you report on, usually eight to twelve quarters, in a single pass with a dated note explaining what changed. Rolling restatements, where each quarter uses slightly different rules, are worse than the original problem because the trend line becomes meaningless.

If your CRM, your invoicing system and your board deck are telling different stories, that is a data model problem, not a discipline problem. We fix it as part of our CRM and RevOps work, and connect it to the automation layer so the numbers stay right without anyone maintaining a spreadsheet. Get in touch and we will show you the three fixes we would make first.