Auto-renew off without an explicit cancel bills as an Extended Service Term

In the Microsoft CSP program, turning auto-renew off does not cancel an EST-eligible subscription. With no explicit cancel instruction attached, Microsoft converts it at term end into a paid Extended Service Term that renews monthly, and the API returns the expected answer first.

Last verified: 2026-08-20.

What changed

Extended Service Terms replaced the two-option end of term model, enforced from 4 May 2026. Microsoft's Extended service terms reference, read on 2026-08-20, states the rule: "Subscriptions eligible for EST with auto renew false, without cancel details, are converted to EST at the end of the term."

The instruction that ends a subscription is now a scheduled action rather than a flag: "Partners need to explicitly set the scheduledActions to cancel along with autorenw false to cancel an EST eligible subscription at the end of the term." The typo is Microsoft's.

The converted subscription carries a price. Same page: "The extended service term bills monthly at the current monthly term rate plus a 3% uplift (or 23% if no monthly plan exists)." The base is the monthly rate, not the annual rate the subscription was sold on, and the charge has no stopping point: "EST terms renew to continued EST monthly terms unless the partner cancels or converts to other SKUs."

Who is affected

Any CSP partner with an EST-eligible subscription, scoped by Microsoft to "Subscriptions purchased or renewed between April 1, 2025 and May 4, 2026 with term end dates after May 4, 2026", trials and end of sale SKUs excluded. The backfill has run: "February 6, 2026 to February 15, 2026: Conversion backfill of autorenew false to EST."

The misreading is the one a careful operator makes. EST reads as an addition to the menu, so the habit of ending a subscription by switching auto-renew off looks untouched. The operator verifies, and the API agrees: "Partners who continue to set auto renew to false in the APIs after EST features are available initially get a response from the API of autorenew false and cancel at end of term." That agreement has a clock on it: "Subscription updates with only autorenew set to false without scheduledActions of cancel actionType are quickly converted to EST with auto renew true within 24 hours." The confirmation is accurate when read and stops being true later.

A second path arrives with no renewal decision at all. Microsoft's Update a subscription by ID reference warns that a partial PATCH body is destructive: "If these attributes aren't provided, autoRenewEnabled is inadvertently set to false." A script editing a friendly name can set auto-renew false by omission.

The cost lands in three places: a subscription believed cancelled that keeps billing monthly with no end date; a cohort nobody can list from a partner's own systems, because "getSubscriptions doesn't include EST properties per line item"; and an invoice arriving after an offboarding for a tenant the customer was told had closed.

Tenant check

Read what is stored, not what the last write returned.

GET https://api.partnercenter.microsoft.com/v1/customers/{customer-tenant-id}/subscriptions/{id-for-subscription} HTTP/1.1
Authorization: Bearer <token>
Accept: application/json
Host: api.partnercenter.microsoft.com

# Read autoRenewEnabled, scheduledActions and gracePeriodEndDateTime, then
# run the same call again the NEXT DAY. The diff between the two reads is the
# evidence: a read soon after a write can show a state the job has not
# rewritten yet.

A genuinely cancelled subscription shows autoRenewEnabled false plus a scheduledActions entry of actionType Cancel. Do not look for scheduleType TermEnd in the read: that is what the cancel request sets, and Microsoft's documented cancel response returns only actionType and effectiveDate. One on the trap path shows false with no scheduled action on day one, true on day two.

flowchart TD
  accTitle: End of term paths for an EST eligible subscription
  accDescr: A subscription at term end has three documented exits, renew, cancel, or a deliberate move to an extended service term. A fourth, auto renew false with no scheduled action, returns a cancel shaped response where the operator checks, then converts to the same paid term.
  S["Active subscription, term end approaching"]
  R["Renews to new term"]
  C["Cancel at expiration, service ends"]
  E["EST, monthly rate plus 3 percent"]
  T["API says autoRenewEnabled false"]
  N["Read back point, looks cancelled"]
  P["PATCH omitting autoRenewEnabled"]
  S -->|"RenewToNewTerm"| R
  S -->|"Cancel at TermEnd"| C
  S -->|"RenewToExtendedServiceTerm"| E
  S -->|"false, no scheduledActions"| T
  P -.->|"false by omission"| T
  T --- N
  T -.->|"background job, up to 24h"| E
  E -->|"renews monthly"| E

One enumeration path exists across a book of business, and it is not the subscriptions API: Microsoft states that "There isn't an API to return the list of subscriptions set to go to EST at end of term." A conversion webhook covers what happens next but not what already happened, EventName subscription-migrated-to-extended-service-term, firing when a subscription moves from autorenew false to EST, so a partner who wires it today learns nothing about the cohort the February backfill converted. Microsoft documents a conversion webhook, EventName subscription-migrated-to-extended-service-term, firing when a subscription moves from autorenew false to EST. Without webhook plumbing the fallback is the AI Assist export in the customer workspace, prompted with "Please generate a list of all my subscriptions that are set to go to EST at the end of their term." It lands in Downloads, and Microsoft sizes it twice: most requests "may take up to 6 hours to complete and can only be requested once a day", while "Some requests for larger partner tenants may take over 10 hours".

Where two Microsoft pages disagree

Eligibility is defined twice, and the definitions diverge for anything bought after 4 May 2026. The May 2026 Partner Center announcements set no upper bound on the purchase window; the reference page closes it.

Plan against the announcement, the broader reading: being wrong that way costs a redundant explicit cancel rather than an unnoticed monthly charge. Nothing settles it by query, since "there isn't an API call to return EST eligibility."

Limitations

The check reads one subscription and proves only what is stored now. It cannot say whether that subscription is EST-bound, because no EST property is returned per line item, and it cannot confirm eligibility.

The field it depends on is undocumented. The Subscription resource reference lists no scheduledActions property at all, and neither Get a subscription by ID nor the update reference shows it in any example.

The grace period was narrowed rather than abolished: "Effective May 4, 2026, the free grace period for accessing services on nonrenewed subscriptions is discontinued" sits on the same page as "Subscriptions not eligible for EST will keep their 30 day grace periods".

The role granted to run the read is wider than the read: the narrowest of the four roles the Extended service terms page names, Helpdesk agent, can still edit customer details per Roles, permissions and workspace access for users. Nothing here was measured against a live CSP subscription, so the uplift figures and conversion timing are vendor assertions.

Decision

Act now, and the reason is a live default rather than an approaching deadline. Enforcement began on 4 May 2026, the backfill ran in February, and any subscription sitting at auto-renew false with no cancel instruction is already on the path. Read each one intended to end, write an explicit scheduledActions cancel where the answer is wrong, and re-read the next day.

Where a departing customer's subscriptions need an evidence trail that outlives the final invoice, cloud licensing and procurement is the internal path.