Three reasons your NRR is wrong in HubSpot (and how to fix it before Series A)

Why net revenue retention in HubSpot is usually wrong: HubSpot deals record bookings at a point in time, while NRR measures recurring revenue changing across a period. Three gaps cause most errors. Recurring revenue derived from the deal Amount property rather than from line items with recurring billing terms. Expansion and contraction logged in the same pipeline as new business, or not logged at all. Churn and downgrades recorded without a consistent amount or effective date. Fixing all three means modelling recurring revenue, post-sale changes and lost revenue as separate, dated events, then reconciling to finance.

If you are calculating NRR from HubSpot deal data, there is a good chance the number is wrong. Here is why, and how to fix it before an investor asks.

Net revenue retention is one of the first metrics a Series A investor digs into. It is also one of the easiest to get wrong in HubSpot, because HubSpot was built around the sales motion and recurring revenue lives one layer below it. Teams compute NRR from deal amounts, get a number looking plausible, and only discover it does not hold up when someone in diligence pulls the thread.

Reporting assembled after the fact rather than built into the system is one of seven GTM process gaps that break most often as B2B tech companies scale. NRR is where it shows up most expensively.

Here are the three most common reasons your NRR is wrong in HubSpot, and how to fix them before it matters.

How NRR is calculated

NRR measures what happened to a fixed cohort of customers over a fixed period. Take the recurring revenue those customers paid at the start of the period. Add expansion. Subtract contraction and churn. Divide by the starting figure.

NRR = (starting recurring revenue + expansion − contraction − churn) ÷ starting recurring revenue

New customers won during the period are excluded entirely. That exclusion is the part most HubSpot builds get wrong, because new business and existing-customer changes usually sit in the same pipeline with nothing to separate them.

Check yours in twenty minutes

Before rebuilding anything, find out how far off you are. Five checks, all in your own portal.

One. Open the property your NRR report uses. If the measure is Amount or Amount in company currency, the report is measuring bookings. If it is Annual recurring revenue or Monthly recurring revenue, check whether those properties are populated on live deals or sitting empty, because they calculate from recurring line items and stay blank without them.

Two. Sort closed won deals by Amount, descending, and read the top twenty. Look for multi-year contracts where the full term value sits in one field, and for deals blending an implementation fee with a subscription. Each one distorts NRR in a different direction.

Three. Filter all closed won deals by Deal type. If almost everything reads New business, upgrades and renewals are hiding inside new sales. If Deal type is empty on most records, the property is not being used at all.

Four. Search your deal properties for "recurring revenue". Four properties named Recurring revenue amount, deal type, inactive date and inactive reason mean someone has switched on HubSpot's revenue analytics tool. Nothing returned means the tool is unavailable or untouched, and any retention reporting you have is custom-built.

Five. Pick three customers you know downgraded or partially churned in the last two quarters and search for the record. If the change exists only in a Slack thread, a spreadsheet or someone's memory, your contraction figure is understated and your NRR is flattered.

If three of the five checks fail, the number in your board pack is a directional estimate. Worth knowing that now rather than in week two of diligence.

1. You are deriving recurring revenue from deal amounts

The root issue. A HubSpot deal captures a booking, a contract value at a point in time. NRR describes recurring revenue changing over a period. Two different units, and the second one is what the metric needs.

If your NRR is built off the deal Amount field, you are likely mixing one-off and recurring revenue, treating total contract value as if it were annual, and missing every mid-term change never getting its own deal.

The fix: track recurring revenue as recurring revenue. Use line items with recurring billing terms and HubSpot's calculated recurring revenue properties rather than a single deal Amount, or treat your billing or finance system as the source of truth for revenue and reconcile HubSpot to it. NRR should come from what customers pay over time.

In HubSpot terms, the build is specific. Add products to the product library with recurring billing enabled, then attach them to deals as line items rather than typing a figure into Amount. Set Billing frequency, Term and Billing start date on each line item so the deal-level Annual recurring revenue, Monthly recurring revenue and Total contract value properties calculate rather than being entered by hand. Keep one-off revenue on separate line items with a one-time billing frequency so implementation fees never enter the recurring figure. Report on it with the custom report builder using the Deals and Line items data sources together, which is the only way to see the composition of a deal amount instead of the total. HubSpot's built-in line item revenue reports give you closed won and open recurring revenue broken down by product, which is a useful sense check while you build.

If billing lives in a dedicated system, invert the direction. Finance holds the source of truth, HubSpot holds a synced recurring revenue property per company, and the reconciliation runs monthly. Either model works. Two competing sources of truth do not. If the platform decision itself is still open, we compare the two for scaling B2B SaaS in HubSpot vs Salesforce in 2026.

2. Expansion and contraction are not captured cleanly

NRR needs you to separate expansion, contraction and churn within your existing customer base, and exclude new business entirely. Most HubSpot setups are not built to do this, because changes to existing customers are not modelled consistently.

An upgrade gets logged as a new deal in the same pipeline as new business, so it inflates new sales and vanishes from retention. A downgrade is not recorded at all. A renewal is a calendar reminder rather than a tracked event. With expansion, contraction and churn tangled together, any NRR you calculate is guesswork.

The fix: model the post-sale motion deliberately. Give renewals and expansions their own deal type or pipeline so changes to existing customers are captured separately from new business, each with an amount and a date.

Concretely: extend the Deal type property with Renewal, Upgrade and Downgrade values, and run existing-customer motion through a second pipeline with its own stages. Renewal deals carry the renewing recurring amount and the renewal date. Upgrade deals carry the incremental amount only, never the new total, which is the single most common double-count in this build. Trigger renewal creation from a deal-based workflow on the Billing end date property rather than relying on a calendar reminder, and associate every one of these deals to the original company so cohort reporting holds.

Use HubSpot's own vocabulary for those values. New business, Renewal, Upgrade and Downgrade are the four options on the native Recurring revenue deal type property, so matching them now means the native reporting works the day your portal moves to Enterprise, and your team never learns two sets of words for the same event. Expansion and contraction stay as the names of the metrics.

Where a customer's revenue moves several times a year, a custom object for subscription changes is cleaner than a deal per change, though custom object creation needs an Enterprise tier. Without it, the second pipeline does the job.

3. Churn and downgrades have no timing or amount

The third gap is on the way down. Churn often gets recorded loosely, a closed-lost here, an unticked renewal there, with no consistent amount or date. Partial downgrades, where a customer stays but spends less, are usually invisible entirely. Both wreck NRR, because the metric depends on knowing exactly how much recurring revenue left and when.

The fix: capture churn and contraction as structured events with the amount lost and the effective date, the same way you would a win. Record the reason too, so the number arrives with a cause attached.

Build churn and contraction as first-class records. Create a Downgrade deal type with a dedicated recurring revenue lost property and an effective date property, and use a required closed-lost reason so the cause is captured at the point of loss. Record the effective date rather than the date someone got round to logging it, because NRR is period-sensitive and a two-week lag moves the number between quarters.

Verify the behaviour of negative amounts in your own portal before relying on them in rollups. A separate positive-value property for revenue lost is more predictable in reporting than a negative Amount, and it keeps your win rate honest.

What your HubSpot tier gives you

Two of the builds above depend on your subscription, so check before you plan a sprint.

Line items with recurring billing terms, plus the calculated Monthly recurring revenue and Annual recurring revenue deal properties, are available across paid Sales Hub tiers. This is the foundation, and most Seed to Series A portals already have access to it.

HubSpot's revenue analytics report, and the four recurring revenue properties behind it, need Sales Hub Enterprise or Service Hub Enterprise. Two things surprise teams here. Those properties are entered manually rather than calculated from line items, products or quotes. And they are separate from the MRR and ARR deal properties despite the near-identical naming. Teams find the report, assume it reads their line items, and wonder why it is empty.

Custom objects need Enterprise too. On Professional, a second deal pipeline does the same job for existing-customer motion.

So if you are on Professional, build the model with Deal type, a second pipeline and a custom report. Same numbers, more configuration, no tier upgrade required.

Define NRR before you measure it, then reconcile every month

Underneath all three gaps is a definitional one. NRR shifts with the cohort you choose, the period you measure, and what you count as expansion versus new. If those are not pinned down, two people will calculate two different NRRs from the same data and both will look defensible.

Definitional gaps break every boundary in a revenue system, not only the retention end. The front-of-funnel version is the same failure in a different place, which we cover in the MQL to SQL handoff most HubSpot portals get wrong.

Before you fix the plumbing, agree the definition: which cohort, over which period, with clear rules for expansion, contraction and churn. Then build the reporting to match.

A definition holds only when something enforces it every month. Without that, the commercial number and the finance number drift apart quietly, and the gap surfaces at the worst moment.

Run it as a fixed monthly cadence. Pull opening recurring revenue, expansion, contraction and churn from HubSpot for the closed period. Pull the same four figures from billing or the finance system. Compare at customer level, not in aggregate, because two offsetting errors net to zero and look like agreement. Then log every variance above your materiality threshold with a cause, and fix the cause in the system rather than adjusting the output.

Most variances trace back to one of four things. A line item start date entered as the contract signature date rather than the billing start. A mid-term change made in billing and never reflected in HubSpot. Currency conversion applied at different rates on each side. A renewal closed won in HubSpot before the invoice was raised.

Two months of this and the variance list gets short. Three months and you have a documented, repeatable process, which is what a diligence team is really assessing when it asks how you calculate NRR.

Why fix NRR reporting before Series A

Because NRR is a headline diligence metric, and a number falling apart under scrutiny costs you credibility at the worst possible moment. Investors want a strong NRR and a number you are able to explain, defend and reproduce from source. Getting the model right before you raise turns a vulnerability into a proof point.

They will read it next to gross revenue retention, because the pair separates two different stories. GRR captures only churn and contraction and never exceeds 100%. NRR adds expansion on top. A company at 105% NRR and 80% GRR is a leaky bucket refilled by a handful of upsells. One at 105% NRR and 98% GRR has a stable base growing steadily. Build both from the same records so the two numbers reconcile to each other.

Benchmark against your own contract size rather than against public software companies. SaaS Capital's private company retention research segments by annual contract value, which matters because expansion headroom differs sharply between an SMB product and an enterprise one.

Fixing it now is also far cheaper. Rebuilding how you track recurring revenue, expansion and churn is manageable at Series A scale and painful once you have years of tangled history behind you.

What to fix first

Order matters, because the plumbing sits underneath everything else.

Sprint one. Fix the unit. Move recurring revenue onto line items with billing terms, split one-off fees out, and stop reporting recurring revenue from Amount. Nothing downstream works before this.

Sprint two. Model the post-sale motion. Extend Deal type using HubSpot's own values, stand up the renewal and expansion pipeline, set the workflow trigger on billing end date, and brief the team on which record type to use when. The process change is the harder half of this sprint.

Sprint three. Capture the downside. Downgrade records, revenue lost and effective date properties, required loss reasons.

Sprint four. Agree the definition and build the report. Cohort, period, expansion versus new business, then a custom report the whole leadership team reads from a single source.

Sprint five. Start the reconciliation loop and let it run for two closes before the number goes anywhere external.

Historical restatement is the judgement call. Full retrospective cleanup rarely pays for itself. Restating the last four to six quarters usually does, since it gives an investor a trend line rather than a single clean quarter with no history behind it.

The point

If your NRR comes out of HubSpot deal amounts, treat it as a rough indicator rather than a number to put in front of a board or an investor. Track recurring revenue properly, model expansion, contraction and churn as separate dated events, agree the definition, and reconcile with finance. Do that and NRR becomes a metric strong enough to stand behind, which is exactly what Series A asks of it.

If you are heading toward a raise and want your NRR and retention reporting to hold up in diligence, a RevOps Audit will show you where the numbers break and how to fix them. 

Lewis Chawko is the founder of ROC, a fractional RevOps consultancy helping B2B tech startups and scaleups build revenue systems that scale on HubSpot.

FAQs