To forecast renewals, treat signed revenue and the renewal decision as two separate questions. Signed revenue goes into a revenue schedule on the deal, set up while the deal is still open, split into monthly, quarterly or yearly periods, so next year’s committed revenue is the sum of the periods dated next year. The renewal decision gets its own opportunity, and only the next one. Create it when someone will work on it, or give it a countdown of tasks so that it does not sit in the pipeline with nobody working on it. In Coevera (formerly Pipeliner CRM), both parts have a native tool: a revenue schedule and a recurrence rule. The Coevera help center says revenue recognition, which creates the revenue schedule, is available to Business & Enterprise tier customers. See the pricing page for the current plans. When someone asks “what does next year look like?”, a useful answer needs three different things that are usually treated as one.

Why is it hard to forecast renewals?

A company that sells on multi-year terms has three kinds of future revenue:

Committed revenue. A three-year contract signed last quarter already obliges the customer to pay for two more years. This is not a forecast. It is a contract.
Revenue that depends on a decision. A term that ends in March may renew, may renew at a different price, or may not renew. This is a real sales opportunity.
Revenue at risk. A customer who cancels in the middle of a term removes revenue that was already counted.

The usual request, “forecast renewals that don’t exist yet”, mixes all three together.

Why not just create the renewal deals now?

It seems simple: create every future renewal as an opportunity today. The problem is that these records sit in the active pipeline, and nobody works on them for many months. Conversion rate, average sales cycle, stage aging and weighted forecast are all calculated over that pipeline. Fill it with deals nobody is working on, and every one of those numbers gets worse, slowly and without warning. Two other common shortcuts also fail. Putting the whole value of a three-year deal on one closing date makes that month look too high and every month after it too low. And a report of “opportunities closing next year” leaves out every won contract that still pays next year, which is usually the larger number.

How do you keep the two questions apart?

Coevera has a native mechanism for each question:

A revenue schedule on the opportunity spreads its value across dated periods. Set it up before the deal is won: the help center says revenue recognition settings can only be changed on open opportunities. Each period has a date and an amount. The period type is month, quarter or year. The schedule also has a cancellation date field, meant for a contract that ends early. How it behaves has not been tested (see the FAQ below).
A recurrence rule on the opportunity creates the next renewal opportunity. The help center says it makes a copy of the deal when the deal is won or lost. With the “after N months” or “after N years” setting, the copy gets a closing date N months or years after the win or loss date. This matches a contract term, not a fixed calendar date.

Next year’s committed revenue is then the sum of all periods dated next year, across every contract, no matter when each contract closed. The design choice: a recurrence rule puts the renewal into the pipeline on the day the current deal is won, so on a multi-year contract it can sit there for years. Use it only where a countdown of tasks gives people work to do on the renewal, or create the renewal later with a scheduled job, as the production build below does. Let the revenue schedule carry the committed revenue until then.

What it looked like in one production build

The blueprint describes a build that has run in production for years. It creates the renewal opportunity 365 days before the term ends. Then a staged countdown gives people work to do on that record:

180 days: a task for a quarterly business review
90 days: a review invitation to the customer
60 days: a health and value check
45, 30, 18 and 15 days: internal and customer notifications

One “expires in days” field on the account drives every stage. A daily scheduled job creates the renewal. A flag marks when it has been created, so the job does not create a new one every morning. A multi-year flag, used together with a manually-handled flag, stops the standard countdown for three-year contracts, so they do not get renewal activity at the end of years one and two.

When does this approach fall short?

Only three period types, set for the whole company. A schedule uses month, quarter or year. An administrator picks one revenue period for the whole company, and the help center says that if it is Yearly, the only option on a deal is Year. Milestone payments or payments that grow step by step need several opportunities or a separate payment-plan record.
One schedule per opportunity when revenue recognition runs on the opportunity value. An annual license plus a monthly service needs two opportunities, or the Product Line mode, which the blueprint did not test. Check first that your company’s revenue period setting allows a monthly schedule.
Stored renewal-year fields create yearly work. The production build runs a chain of four processes once a year to move “next year” to “this year”. A person runs it by hand.
Part of it is not yet observed. The blueprint read how the schedule and recurrence are set up in a live system, but did not watch periods generate or a recurrence run to the end. Test both in a test copy of your CRM (a sandbox) before you build a forecast on them.

Key takeaways

Treat signed revenue and the renewal decision as two separate questions.
Use a revenue schedule for signed revenue, not future deal records.
Set up the revenue schedule before the deal is won.
Create only the next renewal opportunity, never several.
Only create it early if a countdown gives people work to do on it.
Test period generation and cancellations in a sandbox before you trust the numbers.

Frequently asked questions

How do you forecast renewal revenue before the renewal deal exists?

Split it into two questions. Revenue the customer has already signed for goes into a revenue schedule on the opportunity, set up before the deal is won, spread across monthly, quarterly or yearly periods, each with a date and an amount. Whether the customer renews is a separate sales question, so it gets its own opportunity. Create only the next renewal, and only when someone will work on it.

Can a CRM create the next renewal opportunity automatically?

In Coevera, yes. An opportunity can carry a recurrence rule that creates future opportunities. Its “after N months” or “after N years” setting fits renewals, because a renewal is due one term after the last one, not on a fixed calendar date. The help center says the copy is created when the current deal is won or lost, so on a long contract it waits in the pipeline until the renewal is due.

Why not create all renewal opportunities years in advance?

Because they sit in the active pipeline and nobody works on them. Conversion rate, average sales cycle, stage aging and weighted forecast all get worse. Create only the next renewal, never several, and only when a countdown of tasks and notifications gives someone work to do on it.

How do you record a customer who cancels in the middle of a contract?

The revenue schedule has a cancellation date field, meant for a contract that ends early. Two points need care. First, the help center says revenue recognition settings can only be changed on open opportunities, not on won or lost ones, and a customer cancels in the middle of a contract after the deal is won. Second, the blueprint did not observe what happens to the period records when a cancellation date is set. Test in a sandbox whether you can set the date on a won deal and what happens to the periods, before you rely on this for reporting.

What if the customer pays on milestones instead of a regular schedule?

A revenue schedule only supports month, quarter or year periods. Milestone payments, payments that grow step by step, or a deposit followed by installments need several opportunities or a separate record that holds the payment plan. The full configuration, field list and verification checklist are in the Coevera Blueprint How do you forecast renewals that don’t exist as records yet?

The full configuration, field list and verification checklist are in the Coevera Blueprint How do you forecast renewals that don’t exist as records yet?

PLANNING YOUR RENEWAL FORECAST?

Talk it through with us

If your renewals live in a spreadsheet, or in deals nobody works on, we can walk through how a revenue schedule and a recurrence rule fit your contracts.

Talk to the Coevera Team