When ARR Reporting Breaks: The Case For Custom Snapshot

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-out a purpose-built record we call out a snapshot. This piece walks through what it 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 is it 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:

1. 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.

2. 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.

3. 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 amount of records. 

The deeper point is in decoupling. Your live deals stay editable and messy, the sales team, 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 arrived at the same separation from two completely different starting problems: 

Case one: 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: combine won and renewal opportunities, filter to active contracts, and accept 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: 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: 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: by year, by type, 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: 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.

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.