Forecasting Subscription Renewals in Dynamics When the CRM Data Is Wrong

If you cannot forecast renewals because the subscription data in Dynamics is wrong, separate two problems. Finance needs a defensible renewal number this week, and the CRM needs a data model that can produce one every week. For this week, extract contract start date, term and value for every subscription, flag each record that fails validation, forecast only the records that pass, and hand finance the number with a stated exclusion list and its value rather than a silent guess. For every week after, build the model: a renewal-bearing table with explicit term dates, renewal opportunities generated from end dates, stage probability derived from evidence rather than optimism, and validation that stops bad records entering again.

Why can Dynamics not forecast renewals from the data you have?

Because renewals usually were never modelled. A company launches a subscription product, and the fastest place to record it is the opportunity that won the first deal. The start date is the close date, the term is a line in the description or an attachment, the value is the first year's estimated revenue, and when the customer renews, somebody either edits the old opportunity, creates a new one or does nothing because finance invoices it anyway. After a year or two, the CRM cannot answer the basic questions: which subscriptions end next quarter, what they are worth, and which of them the customer has already agreed to renew.

Dynamics 365 Sales forecasting rolls up open opportunities. It cannot forecast a renewal that has no opportunity, and it cannot know an end date that was never stored in a column. The usual patterns behind a renewal forecast nobody believes are these:

• Subscriptions recorded only as won opportunities, so the end date has to be inferred from the close date and a term typed in free text.
• Term, value and renewal date held in fields sellers edit, with no validation, so values drift, are left empty or carry placeholder dates.
• Upgrades, downgrades and co-terming handled by editing the original record, which destroys the history of what was sold when.
• Renewal opportunities created by hand, late and inconsistently, so the pipeline shows the renewals someone remembered.
• Probability typed by the account owner, who has every reason to call every renewal safe.

How do you give finance a defensible renewal number this week?

Do not try to fix the CRM first. Extract, validate and reconcile, then publish a number that states exactly what it covers.

1. Extract every record that represents a subscription, wherever it lives today: won opportunities, any contract or agreement records, order lines and spreadsheets that sales operations keep beside the CRM. Take the customer, product, start date, term, end date, annual or contract value, currency and owner, with the source record ID.
2. Validate each row against written rules: a start date exists and is not in the future, a term exists and is one of the terms you actually sell, the end date equals start plus term, the value is present and positive, the customer is not a duplicate, and the subscription is not already cancelled.
3. Reconcile to finance. Match the rows that pass against what the finance or billing system has actually invoiced for each customer and product. Where the two disagree on value or dates, the billed figure is the better evidence for this week's number, and the difference goes on a list for correction.
4. Forecast only the rows that pass, grouped by the month or quarter the subscription ends, with a probability rule agreed with finance in advance, even if it is simply "renews unless the customer has given notice".
5. Publish the exclusion list alongside the number: every record excluded, the reason, and its value where one is known. A forecast that says what it leaves out is defensible. One that quietly drops or guesses those records is not.

The exclusion list is also the work plan for the data model, because every reason on it is a rule the CRM should have enforced. If the gap between CRM figures and finance is the wider problem, our post on dashboards that disagree with finance covers how to find and explain the difference.

Should subscriptions be modelled as opportunities or as contracts?

As a separate renewal-bearing record, not as opportunities. An opportunity describes a sale that might happen. A subscription describes an obligation that already exists, with a start, an end and a value, and it outlives several sales cycles. Mixing the two is what makes the data unforecastable.

Dynamics 365 Customer Engagement does not include subscription billing, and the older contract tables in Customer Service were deprecated some time ago in favour of entitlements, which track support terms rather than revenue. Check current Microsoft documentation for the status of any table before building on it. In practice we model subscriptions as a custom table in Dataverse, often called subscription or agreement, related to the account and to the products sold, and keep entitlements for what they do well: support rights and service levels, which belong to Dynamics 365 Customer Service.

How the candidate models compare as the source of a renewal forecast:

• Won opportunity: good for recording how the first sale was made, but it has no term or end date and is edited or duplicated at every renewal.
• Entitlement in Customer Service: good for support terms, cases allowed and service levels, but it describes service rights, not contract value or renewal terms.
• Custom subscription or agreement table: one row per contract with start, end, term, value and renewal status. It has to be designed, populated and kept in step with finance, and it is the model that works.
• Finance or billing system: knows what was invoiced and collected, but not renewal intent, risk or the seller who owns the conversation.

What does a renewal-bearing data model need in Dynamics 365?

Enough explicit columns that no date or value has to be inferred, and enough structure that a change creates history instead of overwriting it.

• Account, with the subscription lines related to products so upgrades and downgrades are visible per product.
• Start date, term in months, end date calculated from them rather than typed, and notice period with the notice date calculated from the end date.
• Contract value and annualised value in a stated currency, with the source of the value recorded.
• Renewal type, such as auto-renewing or requiring a new order, because the two are forecast differently.
• Status, such as active, in renewal, renewed, cancelled or lapsed, set by process rather than typed.
• A link from each subscription to the renewal opportunity that replaces it, and from a renewed subscription back to the one before, so the chain of terms is intact.
• The finance system's contract or customer reference, so the reconciliation can match rows without guessing.

The implementation of the Sales side of this, the opportunity process and the forecast configuration, sits in our Dynamics 365 Sales service.

How do you generate a renewal pipeline from contract end dates?

Let the end date create the opportunity, not the seller's memory. A scheduled process, typically a Power Automate flow or a server-side job, looks for active subscriptions whose notice date or end date falls inside an agreed window, such as a set number of days before the notice date, and creates a renewal opportunity for each one that does not already have one. The opportunity carries the subscription reference, the current value as the starting estimate, the end date as the estimated close date and a renewal type, and it is owned by the account owner or the renewals team.

Because the opportunity is generated from data, the renewal pipeline is complete by construction. A renewal that is missing from the pipeline points to a subscription row that is missing or wrong, which is a data problem to fix, not a seller to chase. Renewal opportunities can then sit in the same forecast as new business, with a category that separates them, so leadership sees retained and new revenue without two systems.

How should renewal probability be set so the forecast is honest?

From evidence recorded on the record, not from how the account owner feels about the customer. Define a small number of renewal stages by what must be true to reach them, and set probability by stage in server-side logic so it cannot be typed.

• At risk: the customer has given notice, raised a cancellation request or has an unresolved escalation.
• Not yet engaged: the renewal window has opened and no conversation with the decision maker is recorded.
• In discussion: a meeting or email with the decision maker is logged against the renewal.
• Confirmed verbally: the customer has confirmed intent, with the contact and date recorded.
• Committed: a signed order, purchase order or accepted renewal quote is attached.

Signals from service are useful evidence here: open high-priority cases, repeated escalations or falling usage where you capture it. The general method for stage evidence, probability set by stage and close-date hygiene is explained in our guide to fixing a broken sales forecast in Dynamics 365, and it applies to renewals with the stages above.

How do you stop bad subscription data from entering again?

Move the rules from the exclusion list into the system, so the next extract has nothing to exclude.

• Make start date, term, value and currency required on the subscription table, and calculate end and notice dates so they cannot disagree with the term.
• Validate on save with server-side logic: no end date before start, no term outside the terms you sell, no active subscription without a value.
• Restrict who can edit term and value after activation to the role that owns contracts, and turn on auditing for those columns.
• Handle upgrades, downgrades and co-terming as new subscription lines or amendments with their own dates, never by editing the original.
• Create subscriptions from the won order or signed contract through a defined step, not by hand afterwards.
• Run the reconciliation against finance every month and give every difference an owner and a closing date.

Which system owns renewal revenue, the CRM or finance?

Both, for different questions. The finance or billing system stays the source of truth for what has been invoiced, recognised and collected, and nothing in Dynamics 365 should overwrite it. The CRM owns the renewal pipeline: which subscriptions end when, who is working them, what the customer has said and how likely each is to renew. The monthly reconciliation keeps the two honest with each other, and where the renewal forecast has to be combined with billed figures in one report, our page on reporting across Dynamics 365 and a finance system shows how to join them with lineage.

Solzet does the CRM side and the integration, not the finance or billing system itself. If per-user licensing is the reason renewals were never modelled in Dynamics properly, because account managers or renewal specialists were left out of the system, a custom CRM built on React, Node.js, PostgreSQL or .NET can hold the same renewal model without Microsoft licences. Our senior consultants and full-stack developers bring 8+ years of Dynamics 365 Customer Engagement, Power Platform and custom CRM delivery, working remotely from Yerevan, Armenia, directly or white-label for Microsoft partners.