# Co-terming in Pipedrive: one renewal date for add-ons

https://salesbond.app/blog/co-terming-add-ons-pipedrive/
Published: 2026-10-06 · Updated: 2026-10-25

Co-terming means a mid-term add-on ends on the same date as the original contract, and the customer pays a prorated price for the stub period between the add-on’s go-live and that date. The shared date is what lets you renew everything in one conversation instead of one per add-on. In Pipedrive, record
 alt_1: “Timeline: 12-seat contract and +3-seat add-on from November 1 both end March 1 at one renewal; grayed alternative with a second renewal in November”
 alt_2: “Two timelines: co-termed add-on priced for 120 of 365 days with one renewal of 15 seats, versus a separate 12-month term with two renewal dates” the add-on as its own deal, with the billing start on its go-live date and the number of billing cycles set to what is left until the shared date. Below: the arithmetic, the two lines that belong in the quote, and the fields that keep a renewal from splitting into five dates.

## Month eight: “can we add three seats?”

Ksenia sells for a team of six. One of her accounts signed for twelve seats on March 1, at 1,200 per seat per year, 14,400 in total, invoiced once a year (all numbers in this article are illustrative). On October 14, Evander, who runs operations on the customer’s side, writes: two new hires start November 1, can we add three seats?

Her first instinct is the obvious one. Three seats, 1,200 each, 3,600, send the quote.

Her second thought, if she has one, is better. Until when?

If the quote says nothing about the end date, the three seats run from November to next November. The account now has a renewal on March 1 and another on November 1, and Cormac, who runs the team, will find out about the second one when a reminder fires in a year that nobody remembers setting. So “until when” gets answered before the price, because the price depends on it.

## Co-terming in one paragraph

Co-terming (some contracts say “co-term”) lines up the end dates of several subscriptions or add-ons so they renew together. The add-on is priced for the shorter period with the formula “full period price × (days until the shared end date ÷ days in the period)” ( [bunny: co-terming](https://bunny.com/glossary/co-terming/)). It covers the usual mid-term additions to an annual contract, such as seats, support packages and services: the co-termed addition starts on the date the new services start and ends when the original contract ends ( [RevOps: co-term](https://www.revops.io/glossary/co-term)). Billing systems call the same mechanic proration, and it’s standard behavior when a subscription changes mid-cycle ( [Stripe: prorations](https://docs.stripe.com/billing/subscriptions/prorations)).

For Ksenia’s three seats:

```
stub price = 3,600 × (120 ÷ 365) = 1,183.56
```

The 120 days are November 1 through February 28 (30 + 31 + 31 + 28), and the renewal is March 1. The 365 is the period the full price covers. Whether you round that to 1,184 or keep the cents is a convention. Pick one and keep it on every quote, because the customer’s finance team will compare.

![Two timelines: co-termed add-on priced for 120 of 365 days with one renewal of 15 seats, versus a separate 12-month term with two renewal dates](https://salesbond.app/wp-content/uploads/2026/10/co-terming-add-ons-pipedrive-2.png)

## Two renewal dates is a quiet cost

The glossary writers put it as arithmetic: four expansions without co-terming and the account has five renewal dates ( [bunny: co-terming](https://bunny.com/glossary/co-terming/)). We’d put it as a calendar. Every renewal date is a reminder, a quote, a signature and an opening for someone on the customer’s side to ask whether they still need the thing. For the main contract that question comes with the champion in the room. For three seats renewing in November it comes from a procurement inbox, with nobody arguing the other side.

No report shows this. The account looks healthy, the seats are in use, and a small line quietly fails to renew because its date was inconvenient. A year later the account owner has changed, and the new owner opens the organization to find four deals with four end dates and no idea which one is the real contract.

We think a renewal should be one meeting with one number, and we’re willing to give up a little revenue on the stub to get it. The prorated price is what buys the single date. Our renewal stages are set by time to expiry, as described in [our customer renewal process in Pipedrive](https://salesbond.app/blog/customer-renewal-process-pipedrive/), and that logic only works if an account has one expiry to count down to.

## Quote in two lines: price for the stub, price for next year

The quote Ksenia sends has two lines, not one.

The first line is the stub: three additional seats, November 1 through February 28, 1,183.56, prorated for 120 of 365 days. The second line is the one most reps leave out: from March 1, fifteen seats at 18,000 a year, one renewal date for everything.

That second line is there for Evander, not for Ksenia. It’s the number he takes to whoever owns his budget, and it means the March renewal arrives as a confirmation rather than a surprise. It also puts the co-terming in writing, so nobody later reads the stub price as the annual price of three seats.

Two things the quote shouldn’t do. It shouldn’t present the stub as a discount: proration is a shorter period at the same rate, and a discount is a separate decision with its own rules, which we keep in [a discount policy for sales teams](https://salesbond.app/blog/discount-policy-sales-teams/). And it shouldn’t promise the 18,000 as fixed if your prices move at renewal. Write “at current rates” if that’s the honest version.

If you generate quotes from Pipedrive put the products on the deal before you generate the document. With product placeholders in a Smart Docs template, Pipedrive fills in the linked product data automatically. Smart Docs is included on Premium and higher plans; on Lite and Growth it’s an add-on ( [Pipedrive: products](https://support.pipedrive.com/en/article/products)).

## What to enter in Pipedrive: start date, remaining cycles, one shared renewal date

The add-on is its own deal on the same organization. The reasons for not touching the won deal from March are in [upsell vs cross-sell in Pipedrive](https://salesbond.app/blog/upsell-vs-cross-sell-pipedrive/), along with the one field that tells expansion types apart, and we won’t repeat them here. That article doesn’t cover the date and the term. Recurring products are only available on Growth and higher plans ( [Pipedrive: recurring products and installments](https://support.pipedrive.com/en/article/recurring-products)), so this is what we fill in on the add-on deal on those plans:

1. **Products.** Attach the seat as a recurring product with the billing frequency the customer is actually invoiced on. The setup order and the cycle limits are in [recurring products vs installments in Pipedrive](https://salesbond.app/blog/pipedrive-recurring-products-vs-installments/).
2. **Billing start date.** The go-live date of the add-on, November 1 in the example. Not the date the quote was signed and not the original contract’s start.
3. **Billing cycles.** A fixed number, equal to the cycles left until the shared end date. Evander’s company is invoiced annually, so the stub is one cycle at the prorated 1,183.56, with the price changed on the deal rather than in the catalog. A custom price set that way applies only to that deal and isn’t saved as a price entry on the product ( [Pipedrive: how can I link products to a deal](https://support.pipedrive.com/en/article/how-can-i-link-products-to-a-deal) ). If a customer is invoiced monthly, the stub becomes four cycles at 300, which adds up to 1,200, not 1,183.56. A billing cycle count is a whole number, and the stub is priced per cycle, not per day. In that case quote 1,200, so the quote and the invoices show the same number.
4. **Renewal date on the organization.** We add a custom Date field on the organization (Personal preferences > Data fields > organization > + Custom field, per [Pipedrive: custom fields](https://support.pipedrive.com/en/article/custom-fields) and [Pipedrive: types of custom fields](https://support.pipedrive.com/en/article/what-types-of-custom-fields-are-there) ) and set it to March 1. Its a signpost for whoever opens the company card. The renewal itself still runs off the Contract end date on the renewal deal, as in our renewal process, and that date stays March 1.
5. **Expansion type.** Upsell, from the field described in the upsell article, so the quarterly count still works.

Points 2–5 are our recommendation, not Pipedrive’s help text. The help page says how to set a start date and a cycle count; we’re telling you which values to put there.

The add-on doesn’t get a renewal deal of its own. If you create renewal deals when a deal is won, by hand or by automation, skip that step for the stub and add the three seats to the renewal deal that already exists, so it carries all fifteen seats for the next twelve months. When that deal closes on March 1, the date on the organization moves forward a year. The stub deal stays won, as it was. On the contract side, the add-on is a [change order or addendum](https://salesbond.app/blog/change-order-addendum-salesforce/) to the agreement already signed.

## What your numbers will say

A deal with a short recurring product on it shows up in the summary with recurring revenue figures, and the forecast meeting will want to know what to do with them. Here is what Pipedrive’s page says and nothing more.

On a deal, ACV, ARR and MRR appear in the summary group, and you can add them as columns in the list view; in Insights, the product revenue forecast report visualizes revenue based on billing cycle and billing date ( [Pipedrive: recurring products and installments](https://support.pipedrive.com/en/article/recurring-products)). The same page defines ACV as the deal’s value for 12 months and TCV as its value over the full term. The rest of the definitions and the formula-field gap are in [our recurring products vs installments article](https://salesbond.app/blog/pipedrive-recurring-products-vs-installments/).

The page doesn’t say how a deal shorter than 12 months is treated in the 12-month figures, and we aren’t going to guess.

So our rule for the stub deal is to read TCV and leave the rest alone. TCV is the money of the stub, which is the only number the stub deal is responsible for. The annual figure for the account belongs to the renewal deal for March 1, a plain twelve-month deal of the kind every definition on that page was written for. If the forecast meeting asks for an annual number before that renewal is won, it’s 18,000 from the second line of the quote, and it’s a quote, not a won deal. Which field holds what is the same rule as for any other deal, and ours is in [ACV vs deal value in Pipedrive](https://salesbond.app/blog/acv-vs-deal-value-pipedrive/).

## When not to co-term

Co-terming is a default, not a law. We give an add-on its own term in four cases.

When the add-on is bigger than the base. If a twelve-seat customer wants forty more seats in month eight, the stub is a large invoice for four months of use, and a fresh twelve-month term is the easier sale. Then the sensible move is the the reverse: at the next renewal, shorten the original to meet the new date.

When it’s a different product with its own life. An onboarding project or a fixed-length services engagement ends when the work ends, and tying it to a software renewal date helps nobody.

When it’s a different budget. If Ottilie in another department is paying for the add-on from her own line, she may need her own renewal date to match her own budget cycle. Forcing her onto Evander’s date trades her convenience for yours.

When the stub is too short to be worth invoicing. Three seats for three weeks is an invoice that costs more to process than it earns. Quote it as part of the renewal, start it on the shared date and let the three weeks go.

In the first three cases the add-on gets its own renewal deal with its own Contract end date, and the renewal pipeline, sorted by end date, shows both. The date on the organization keeps pointing at the main contract. Two dates, on purpose this time.

One last note on what happens downstream. Customer Health, one of the products we build at SalesBond, reads a customer’s buying cycle from won deals, so a won stub deal counts as a purchase like any other and the shared renewal date isn’t something it looks at. That’s deliberate: the product watches whether customers keep buying, and the date you write down is yours to manage. To see how your current accounts look against their own buying history, [check your CRM with SalesBond](https://salesbond.app/).