Lucas TraikoffCRM-native ARR reports break because a CRM stores only the current state of each deal. It forgets history, cannot spread a multi-year contract across years and blends one-time fees into recurring revenue. The fix is a custom ARR snapshot, which is one record per contract year holding recurring revenue by type and date, so the waterfall stops moving when someone edits a deal.
Ask a founder what their ARR is and typically, you'll get a confident, round number. Ask them to prove it, break it down year by year, or show you how it moved over the last two quarters, and the confidence tends to disappear quickly. The number that anchors your board decks, your fundraises, and the comp plans of many of your team members often turns out to be the softest number in the business.
We run revenue operations for a portfolio of B2B software companies, and we've watched this play out enough times to see a pattern. When ARR reporting breaks, it usually breaks for one of a few reasons, and the fix is nearly always the same. Stop asking the CRM to calculate ARR live, and instead build a purpose-built record we call a snapshot. This piece walks through what that means and two very different engagements where a custom snapshot was quietly the piece that made finance's numbers make sense again.
The number that never sits still
Annual recurring revenue (ARR) sounds like a single figure, but it is really a question with a date attached. What is our recurring revenue as of today? As of the end of last quarter? As of a year from now, once these renewals land and those contracts expire? Every one of those is a different number, and a healthy business needs to see all of them.
The trouble is that CRMs like Salesforce and HubSpot are built to manage deals in flight, not to remember what your revenue looked like at a moment in time. Their native reports read the live state of your records right now. That works well for a pipeline report. It falls apart for ARR, for three reasons that show up again and again.
- First, there is no memory. A native report can tell you what a deal says today, not what it said in March. The moment someone edits a closed contract, discounts a renewal, or corrects a value, the history is gone, and with it any hope of an accurate ARR waterfall showing how you got from last year's number to this year's. In Xactly's 2024 survey of 405 sales and finance leaders, 66% said their reporting systems could not access historical CRM or performance data (Xactly, 2024).
- Second, multi-year contracts break the model. A three-year deal worth €300k is not €300k in ARR, and it's often not even €100k per year, because the annual amount can step up or down across the term. A single amount field in a single opportunity cannot represent revenue that lives in several different years at once. Teams end up cloning records by hand, and then the manual copies drift out of sync almost immediately. In the EU, customers can now also switch providers mid-contract under the Data Act.
- Third, recurring and one-time revenue get blended together. Onboarding fees, professional services, and setup charges all land in the same total as subscriptions and licenses. Unless something separates them, your ARR quietly inherits revenue that will never recur, and the number that investors care about most is now the most likely to be wrong.
What a custom snapshot actually is
The fix is less exotic than it sounds. Instead of asking a report to derive ARR on the fly from live deals, we create dedicated records whose only job is to hold ARR the way you need to see it. Those records are the "snapshot".
In practice, this usually means an object attached to all deals or opportunities. When a contract closes, automation reads it and generates one child record per year of the term. A one-year contract produces a single record. A three-year contract produces three, each carrying that year's recurring amount, its revenue type, and the dates it covers. Each record classifies revenue as recurring or one-time, so subscriptions and usage count toward ARR while onboarding and services do not.
Once the data lives in that shape, reporting becomes pretty straightforward. Simple roll-ups aggregate ARR by year, by revenue type, by product, or by account. You can show active ARR as of today, ARR expiring next year, and the renewals and expansions that will replace it, all from the same set of records.
The deeper point is in decoupling. Your live deals stay editable and messy, and the sales team works uninterrupted. Your ARR lives in a separate, stable layer that records what is true and does not silently rewrite itself when someone touches an opportunity. That separation is what turns ARR from a number people argue about into a number that people trust. The two engagements below, both anonymised, arrived at the same separation from two completely different starting problems.
Case one is the dashboard that was wrong by millions
The first was a growing B2B software company selling multi-year subscriptions with a mix of licenses, usage, and onboarding fees. Its ARR dashboard read roughly 3 million dollars. Its actual closed-won ARR was closer to 5.5 million. A gap that size is not a rounding error; it is the difference between a company that looks stalled and one that is growing fast, and it was showing up incorrectly in the numbers leadership used to run the business.
The causes were exactly the ones above, compounded. Around 2 million dollars of business sat in opportunities that had never been logged cleanly, so native reports simply could not see it. Historical contracts carried manual calculation errors, including deals whose usage-based pricing did not reconcile to the recorded contract value. And because the CRM had no way to show cumulative ARR over time, the team had resorted to a fragile workaround. They combined won and renewal opportunities, filtered to active contracts, and accepted that open new business was invisible. The dashboard was not lying so much as answering a question nobody had actually asked.
We built an ARR Snapshot object on top of the company's existing quote-to-deal structure. When a contract closed, automation annualized it into one snapshot record per product, per year of the term. A one-year deal generated a single record; a multi-year deal generated one for each year. Each line was tagged recurring or one-time, so the contract's total value and its recurring ARR were finally distinct quantities rather than the same figure wearing two hats. Roll-up fields then aggregated ARR by year and by revenue type across the whole book.
The reporting standard also changed. Instead of quoting an average or the full contract value, everyone moved to Year One ARR as the common currency, from the sales tool through to how account executives were paid, so the same definition ran end to end. Closed deals automatically generated the next cycle's opportunity and a fresh set of snapshots, which meant the team could project renewals two and three years ahead and see, at any moment, which ARR was active, which was expiring, and which expansions were due to replace it.
None of this was instant. The ARR definition itself was refined four or five times in the first couple of months as edge cases surfaced, from expansions with mismatched end dates to historical deals that needed re-auditing. That is the honest reality of this work. The snapshot object gives you a place to be right, but you still have to do the reconciliation to get there. What changed permanently was that the company finally had one source of ARR truth, backed by the underlying products, instead of a dashboard that quietly drifted every time a rep edited a deal.
Case two is about getting the story straight before diligence
The second engagement was a sustainability software company heading into a funding round, where the ARR waterfall was not a nice-to-have but a due-diligence dependency. Commission plans, quarterly and annual targets, board reporting, and the company's OKRs all hung off it, and commercial and financial diligence were running in parallel. The forecast even had to stretch from two years to three to satisfy the process. This was a case where getting ARR wrong would not just mislead the team; it would be examined line by line by outside investors.
Here the earlier, simpler approach had actually become the problem. The company had been relying on static, point-in-time ARR figures, and those figures obscured exactly the things diligence cares about. Multi-year deals with amounts that varied year to year were flattened into a single number. Early renewals and expansions overlapped with their original contracts, double-counting revenue across quarters. In one case an expansion bundled original and new products together, with subscription dates that overlapped by roughly five months, and the static snapshot had no way to represent that cleanly.
The response combined two moves. First, we protected the integrity of the waterfall itself. When someone proposed applying a renewal discount by rewriting historical product data, we pushed back, because doing so would have corrupted the ARR history, the commission calculations, and the board numbers all at once. The rule became simple. Never rewrite the past. Apply the discount at renewal, annotate the change, and let the record show what actually happened. Tricky scenarios got explicit treatment rather than fudging, so a three-year deal with a three-month break clause was handled as a short non-recurring pilot up front, then standard ARR from month four if the customer stayed.
Second, the snapshot evolved from a single figure into a schedule by contract year. A €300k contract was no longer one number; it was €100k a year across three years, each with its own invoice dates, and each captured as its own record. That per-year schedule fed the waterfall directly and doubled as the backbone of a finance exercise. Working contract-first, the team documented what should have been invoiced and when, then reconciled that against historical accounting records and drafted the missing future invoices. The contract was treated as the source of truth, and the accounting system was made to match it, rather than the other way around. That sequencing mattered, because it surfaced real revenue leakage, including separately contracted services that had never been billed.
The payoff was a waterfall the company could actually stand behind. By mid-January it was functional and totalled 5.4 million dollars for the year, pending final validation against invoicing data, with only a handful of opportunities still missing their ARR. Going into diligence, the difference between a number you assert and a number you can trace, contract by contract and year by year, is the difference between a smooth process and a painful one.
Why it keeps being the answer
These were different companies, on different CRMs, with different problems. One was undercounting ARR by millions; the other was overcounting through double-counted overlaps and flattened multi-year deals. One needed to convince its own leadership; the other needed to convince investors. Yet both arrived at the same structural fix, and that is not a coincidence.
The reason is that ARR is fundamentally a time-series question being asked of a system designed to store only the present. No amount of report-building fixes that mismatch, because the information you need, what revenue was recurring, in which year, as of when, simply is not present in a single live deal. You can only report on data you have captured, and native records do not capture it. A snapshot does. It records ARR in the shape the question is actually asked in, which is by year, by type and at a point in time that stays put.
Everything else follows from having that data in the right shape. Roll-ups become trivial. Waterfalls become honest, because history stops moving underneath them. Comp plans and board decks draw from the same records, so sales, finance, and the board are finally arguing about strategy instead of about whose number is right. The snapshot is not clever; it is just the difference between deriving ARR under pressure and having already captured it.
If this sounds like your business
You probably do not need a snapshot layer on day one. When every deal is a one-year subscription and you have a few dozen customers, the native reports are fine. The pattern earns its keep once complexity arrives, and there are a few reliable signs that it has.
The clearest tell is that you no longer fully trust your own ARR number, or that two people in the company can produce two different versions of it. Close behind is the multi-year contract that nobody is quite sure how to report, the renewal or expansion that seems to double-count, and the finance and sales teams working from figures that never quite reconcile. If you are approaching a fundraise or an audit, the bar rises again, because you will need to trace ARR by year and by contract, not just assert a total, and a spreadsheet rebuilt from memory will not survive scrutiny.
If you are not sure how far your own ARR number can be trusted, our CRM and GTM Health Check ranks the gaps and fixes the first one.
The encouraging part is that this is a solved problem. You do not need to migrate systems or buy another platform; in both cases above, the answer was built inside the CRM the company already had. What it takes is treating ARR as data to be captured deliberately rather than a number to be derived under pressure, and being willing to do the reconciliation work once so that the number stays right afterward.
If your ARR has started to feel more like an argument than a fact, that is usually the moment the snapshot pattern pays for itself. It is one of the highest-leverage pieces of revenue plumbing a growing software company can put in, precisely because everything downstream, forecasting, comp, and the story you tell investors, depends on getting this one number right.
FAQ
What is ARR reporting?
ARR reporting shows the annualised value of your recurring contracts at a point in time and explains how it moved between two dates. A sound ARR report separates recurring from one-time revenue, splits multi-year contracts by year and can be reproduced for any past date.
Why doesn't the ARR in our CRM match finance's number?
Usually because they measure different things at different moments. Native CRM reports read the live state of deals, so history changes whenever someone edits a record. HubSpot's default ARR property, for example, is calculated from a deal's recurring line items and term length, not the deal amount (HubSpot), while finance works from billing data. Agree one definition and reconcile record by record.
What is an ARR waterfall?
An ARR waterfall, or bridge, explains the change in ARR over a period. Beginning ARR, plus new and expansion ARR, minus contraction and churn, equals ending ARR. Our Five Dots method builds it customer by customer, counts recurring revenue only and shows movements gross, because an expansion and an equal churn are not "no change".
How should multi-year contracts count toward ARR?
There is no universally correct convention, but there must be one, agreed with finance. The choices we see most often are Year One ARR for bookings and commission, year-by-year values for the waterfall, average ARR for ramp deals, and the final year's ARR as the renewal base. Total contract value should never flow into ARR.
Can HubSpot or Salesforce report ARR natively?
Both can report on recurring revenue fields, but what they show depends on how deals are structured. HubSpot's recurring revenue analytics, for example, need an Enterprise subscription and read manually entered recurring revenue properties, not the products or quotes on a deal (HubSpot). For multi-year contracts and a waterfall finance will sign off, most teams we work with add a snapshot object.
