A term that isn't a whole number of months

Last week I wrote up how to model a co-termed upsell on Deals and Line Items alone, for a company not using Quotes, Contracts or Revenue Hub. Six days later HubSpot put the native version into limited beta: you can add a new line item to an existing contract and have it end on the contract's end date instead of pushing that date out. I want to write about it while the two things are still next to each other, because the reason it did not work before is more useful than the fact that it now does.

Why a mid-contract add moved the renewal date

HubSpot's own explanation is one clause long and it is the whole story: adding a line item through a change quote always extended the contract's end date because terms could only be set in whole months or years.

Sit with that for a second, because it sounds like a limitation about rounding and it is actually a limitation about arithmetic. A contract signed on the 14th of January for twelve months ends on the 13th of January. A customer who buys something on the 2nd of May has eight months and eleven days left. There is no whole-month term that expresses eight months and eleven days. So the platform had two options, and both of them are wrong: set eight months and the add-on dies in early January while the original runs to the 13th, or set nine and the contract's end date moves out to February and every renewal report the business runs is now describing a different agreement than the one on paper.

It picked the second one. Which, if you have only ever read about this rather than watched it happen, sounds like a minor date discrepancy. What it means in practice is that a rep doing a routine mid-term add silently re-dated the contract, and nobody found out until somebody noticed the renewal had drifted.

The beta closes it by computing the exact term — prorated or fractional — so the new line lands on the existing end date. Proration has to be enabled, which makes sense once you see what it is doing: a partial term has to be billable before it can exist. And if you actually want the contract extended, you edit the line item and set the billing term yourself, at which point the align-with-contract option turns itself off.

My worked example was too clean

Last week's piece used a nine-month stub, and nine months is a whole number of months, so the example never touched the thing that actually breaks. That was not carelessness exactly — a round number is easier to follow and the modelling logic is the same either way — but it did mean the piece described the shape of the problem without landing on its cause. Real add-ons do not arrive on anniversary dates. They arrive on the 2nd of May with eleven days hanging off the end, and those eleven days are the entire reason the native path did not exist until now.

So if you read that piece and thought the manual model looked like more work than it should be, you were right, and the reason was upstream of anything I could have modelled around.

Expansion and cross-sell are not the same motion

This is the distinction I expect most of the coverage to blur, and it decides whether you have ever hit this problem at all.

Expansion

More of something the customer already has. Going from fifty seats to seventy, or from four covered machines to six, or adding a fifth monitored site. It is a quantity change on a line item that already exists, so its dates never move and there is nothing to co-term. This always worked.

Cross-sell

Something the customer did not have before. Adding premium support, or a sandbox, or a second product line. It is a new line item, so it needs its own term, and until this beta that term had to be a whole number of months. This is what did not work.

That is why some businesses have never met this and others meet it constantly. If your catalog is built so that growth means a bigger number on an existing row, you have been fine the whole time and this beta changes nothing for you. If growth means a new row, every mid-term sale you have made has been quietly moving your renewal dates.

What it does not fix, which is the part that decides who can use Revenue Hub at all

A line item carrying an end date and a billing term is a recurring line. So this co-terms a recurring add, and it says nothing at all about one-time ones. The sentence that decides whether a business fits is HubSpot's own, from the knowledge base in August: change quotes can only update recurring line items, not one-time line items.

That still stands, and it is the harder limit. Anything one-time added after signature — a change order, a milestone, a deposit, a phase of work, extra devices on an install — is a separate quote and a separate motion somebody has to own. For a software company selling seats, that is an inconvenience. For a contractor whose whole commercial life is variations on an install, it is the reason the platform does not fit yet, and one co-term beta does not move it.

I am pointing at that deliberately, because a feature announcement is the moment when a limitation gets quietly assumed away, and this one is easy to read as more than it is.

Who can actually use it

Revenue Hub Professional or Enterprise, which is worth noting because it is not Enterprise-only and a lot of the interesting mid-market portals sit on Professional. Then it is limited beta, described as being for customers who have identified this gap as a roadblock, and the note names a product manager to write to with a description of how it affects your workflows. If you have real evidence of the drift, that email is a short one.

Two ways in once you are enrolled: a change quote from the contract record, or a direct edit if your portal is also in the Direct Create and Edit beta. Two betas stacked is worth knowing before you promise anybody a timeline.

Which means last week's manual model is still the answer for most people reading this. If you are not on Revenue Hub, or you are and you are not in the beta, the stub line at quantity equals months remaining is still how you get honest recurring revenue out of a co-termed upsell. That piece has not aged, it has just acquired a ceiling.

One thing I have not checked

A term is normally derived from how many payments a recurring line is set to make: a three-year agreement is three annual payments, and a text field on a deal saying three years drives nothing. A fractional term does not factor into whole payments. So I do not know what the billing period property holds on a co-termed partial line, or what the number-of-payments property reads, and I have not been able to look — the contracts object returns a permissions error on every portal I have a key for.

I would want that answered before teaching the payments-count model to anyone as though it were unqualified, because if it has changed shape then a lot of reporting built on it is describing something slightly different than it used to. If you are in the beta and you pull that property, I would genuinely like to know what it says.