Copilot Credits go default-on: your 2 November checklist

On 16 September Microsoft told its CSP partners that from 2 November 2026, every new Microsoft 365 Copilot Business licence sold through the Cloud Solution Provider channel arrives with usage-based billing switched on. Pay-as-you-go is the default billing configuration, the Azure subscription needed to carry the meter comes with the purchase, and the licence unlocks experiences that bill in Copilot Credits rather than per seat: Copilot Cowork, the Work IQ APIs and GitHub Copilot Harness. If your organisation buys Microsoft 365 from a reseller rather than direct from Microsoft, that is the CSP channel, and the seats you add in November will behave differently from the ones you bought in September.

The change is small in wording and large in consequence. A per-seat subscription has a knowable annual cost. A consumption meter attached to that subscription does not, unless somebody configures a limit. The configuration surface exists, it is documented, and almost none of it is on by default in the shape a finance team would choose.

What changes on 2 November, and what does not

The announcement is narrow. It applies to new purchases of Microsoft 365 Copilot Business, standalone and in bundles, made through CSP. Licences you already own are not named in it, and neither are the enterprise Copilot SKUs. What arrives with those new licences is the billing plumbing: Microsoft describes it as "less setup friction", because the Azure subscription setup required for usage-based billing now ships with the licence instead of being a separate multi-step task for the partner.

The seat price itself is unchanged by this. Microsoft 365 Copilot Business lists as an add-on at 18.00 US dollars per user per month paid yearly, reduced from 21.00, or 25.20 per user per month billed monthly, and it still requires a qualifying Microsoft 365 plan underneath. Credits sit on top of that number, not inside it.

One detail deserves a caveat. The Partner Center announcement tells partners to familiarise their teams with "the preset monthly limit" but does not publish the figure on that page. Do not plan around a number you read in a partner blog. Open the tenant, look at what the default spending policy is actually set to, and treat that value as the only one that matters.

What a Copilot Credit is and what burns one

Copilot Credits are Microsoft's common currency for usage-based billing across eligible services. In the Microsoft 365 admin center the services currently governed by this model are Cowork, apps built with Cowork, and the Work IQ API. Microsoft states plainly that more agents and services will be added over time, which matters more than it looks: there is a setting that decides whether those future services join your existing spending policy automatically.

For the unit price, the most useful primary reference is Microsoft's own pre-purchase plan documentation, which works its sizing example at a pay-as-you-go rate of 0.01 US dollars per Copilot Credit. Prepaid capacity packs are sold as a fixed monthly allowance of 25,000 credits per pack, tenant-wide and replenished at the start of each billing period. When a spending policy has more than one funding source available, consumption runs in a fixed order: capacity packs first, then pre-purchase plan credits, then pay-as-you-go.

What Microsoft does not publish is a fixed credit cost per Cowork task. The clearest evidence of that is a feature: users can type /cost inside Cowork to see the approximate credit cost of the task they have open. A product only ships a cost-inspection command when the cost is not a constant you can look up in advance.

The five settings that decide your bill

Everything lives in the Microsoft 365 admin center under Copilot > Cost management. Five decisions there determine whether your Copilot spend is a budget line or a surprise.

• 1. The tenant-level monthly limit. When you activate the default spending policy, you choose between "Don't limit monthly spending" and "Limit monthly spending". The default setup targets your entire organisation and all users. This is the single most consequential radio button in the flow.
• 2. The per-user monthly limit. Optional, and Microsoft's own documentation recommends setting it "to prevent runaway spending of Copilot Credits by one individual user". A tenant cap alone still allows one enthusiastic user to consume the whole month for everyone else.
• 3. Auto-apply new services. Turned on by default for spending policies. Leave it on and every future Copilot service or agent Microsoft adds to this billing model is automatically covered by the policy, with no review step. Turn it off on any policy where you want new services approved before they can spend.
• 4. The billing method. Once you set a billing method on a spending policy and create the policy, you cannot change it. Fixing a wrong Azure subscription means deleting the policy and building a new one.
• 5. Alerts. You can set a threshold as either a credit amount or a percentage, and choose who receives the email. Alerts start when usage crosses the threshold and repeat weekly until the monthly period resets or you change the policy. The field prepopulates with the signed-in administrator, which is rarely the right distribution list.

Two behaviours around policies catch people out. Additional spending policies do not inherit the tenant-level limit; each one carries its own independent limit. And when a user falls under more than one policy for the same service, the system picks by highest per-user limit, then by largest overall policy limit, then by the most recently created policy. Build a generous policy for one pilot group and you may have quietly raised the ceiling for anyone who also belongs to it.

Moving people between Entra ID groups does not reset anything. Credits consumed under the previous policy stay in the user's consumption history and count against the limit in the new one for that billing period.

What happens when someone hits the cap

Users who reach their limit within a policy lose access to the governed agents and services for the rest of the month, until credits reset on the first. They can request more credits from inside the experience, and those requests land in a Credit requests queue for an administrator to approve, reject or route. If your organisation already runs approvals in ServiceNow or an internal portal, custom request policies can redirect users there with your own message and link, while the request still appears in the audit view labelled as handled externally.

A running task that crosses a per-user limit is allowed to finish. Microsoft states the excess does not count toward the policy limit and is not billed, at its sole discretion, and it will not appear as consumed credits in the dashboards.

Now the part that argues for hard caps rather than alerts. The Overview tab refreshes every four hours and the Consumption tab every two. A runaway day is something you read about tomorrow morning. An alert threshold is a smoke detector; the policy limit is the fuse.

Cost math to do before anything is switched on

Since per-task credit consumption is not published, the only honest way to budget is backwards from the cap you are willing to sign for. Take the 0.01 US dollar per credit figure Microsoft uses in its own sizing example and the arithmetic becomes simple.

Per-user cap you set        Monthly exposure per user (at 0.01 USD/credit)
    500 credits                       5 USD
  1,000 credits                      10 USD
  2,500 credits                      25 USD

200 seats, 1,000-credit per-user cap:
  worst case            200 x 10  =    2,000 USD / month
  annualised                          24,000 USD / year
  add-on seats at 18 USD (annual)     43,200 USD / year
  credit ceiling as share of seats        ~56%

That last line is the number to take to a finance conversation. A modest-sounding per-user credit allowance can represent a very large fraction of what you pay for the seats themselves, which is precisely why the tenant policy limit should be set to something defensible rather than left unlimited. Real consumption will be far below the ceiling for most organisations. The ceiling is what you are exposed to until you set one.

For the prepaid side, Microsoft's documentation illustrates the trade with a worked example: 1,500,000 credits of expected annual consumption costs 15,000 US dollars at the pay-as-you-go rate, and a Tier 2 pre-purchase plan of 15,000 commit units priced, in Microsoft's own illustrative wording, at 14,100 US dollars would save 6 per cent. Treat the tier price as illustrative rather than a quote, and note the surrounding terms: a pre-purchase plan runs for a one-year term, renews automatically by default, and cannot be cancelled, exchanged, split or merged. All purchases are final.

The decision rule follows from that. Run pay-as-you-go with a hard cap for 60 to 90 days, read the Consumption tab by user and by service, and only then decide whether a capacity pack or a pre-purchase plan beats the meter. Prepaying before you have usage data commits you for a year to a number you guessed.

The CSP wrinkle: who owns the Azure subscription

Usage-based billing charges land on an Azure subscription, which raises an awkward question for organisations whose entire Microsoft estate is Microsoft 365 and nothing else. Many of them have never had an Azure subscription, and after 2 November they will.

For partner-managed and CSP customers, Microsoft's setup guidance is explicit: the Azure subscription used for billing must be associated with the partner's billing account. If the customer already has one, it needs to be associated; if not, the partner creates it through the Azure portal or Partner Center. Inside the admin center, if the signed-in administrator has no access to any Azure subscription, the system creates one automatically using the billing account linked in the Microsoft 365 admin center, and that path requires Global Administrator. Under Advanced billing settings, an Owner or Contributor on the subscription can choose the billing region and the resource group where the billing policy is deployed. If no resource group exists, one is created for you.

The practical consequence is that consumption arrives on the Azure side of your relationship with the reseller, not on the familiar per-seat Microsoft 365 line. Whoever reconciles invoices should be told this before the first one lands.

If you hold an Azure Consumption Commitment, there is a setup trap worth reading twice. Eligible Copilot consumption can count toward a MACC, but only when the selected subscription links to the billing account that holds the commitment. Pick a different subscription and you still pay for the consumption; it simply might not count against what you already committed to spend. Verify this before usage starts, because the billing method cannot be changed after a policy is created.

The Swedish and EU angle

Three things make this change sharper for Swedish and EU buyers than the announcement suggests.

The CSP channel is the normal route here, not an edge case. Most Swedish small and mid-sized organisations reach Microsoft 365 through a reseller, which means this default applies to the mainstream purchasing path rather than to some specialised segment. If your licensing conversation happens with an account manager at a Swedish partner, the 2 November default is yours to configure, and the window to do it is the gap between the licence landing and the first user opening Cowork.

Prepaid credits carry currency risk. Pre-purchase commit units are bought at discounted tiers in your purchasing currency, and Microsoft's documentation states that purchased units pay down qualifying costs in US dollars. A Swedish buyer commits kronor for a year against consumption priced in dollars. On a one-year, non-cancellable commitment, that exchange-rate exposure belongs in the business case next to the headline discount percentage, not as a footnote. The same caution applies to the Azure-side AI meters generally; we walked through the equivalent arithmetic when the EU Data Zone premium in Microsoft Foundry changed.

Public-sector and regulated buyers need a documented cap, not an alert. A licence purchase that also opens an unlimited consumption meter is difficult to reconcile with a fixed procurement budget and with the internal control expectations that come with it. The defensible configuration is a tenant policy limit and a per-user limit, both set to numbers that appear in your budget, with reader-based roles assigned so finance and governance stakeholders can review consumption without holding permissions to change spending policies. Microsoft supports exactly that separation: AI Reader, Global Reader and other reader roles see the dashboards and reports, while only Global Administrator and Billing Administrator can set or change a billing method.

The checklist before 2 November

• 1. Confirm your purchasing path. Establish whether your Copilot Business licences come through CSP and whether any new seats are planned after 2 November. If both are true, this applies to you.
• 2. Open Copilot > Cost management and read the current state. Check whether a default spending policy exists, what its monthly limit is, and whether a per-user limit is configured.
• 3. Set a tenant limit you can defend in a budget meeting. "Limit monthly spending" with a real number, not "Don't limit monthly spending".
• 4. Set a per-user limit as well. The tenant cap protects the company. The per-user cap protects the tenant cap from a single user.
• 5. Decide on Auto-apply new services deliberately. On means future Copilot services spend under this policy without review. Off means you approve each one. Either can be right; the default should not be an accident.
• 6. Choose the Azure subscription carefully. It cannot be changed after the policy is created. If you have a MACC, confirm the subscription sits under the billing account that holds the commitment.
• 7. Fix the alert recipients. Replace the prepopulated administrator address with the distribution list that actually watches cost, and set the user-level notification threshold if you configured a per-user limit.
• 8. Assign reader roles to finance. AI Reader or Global Reader gives them the consumption dashboards without any ability to change policies or billing methods.
• 9. Decide how credit requests are handled. Either someone owns the queue in the admin center, or you configure a custom request policy that redirects to your existing approval workflow.
• 10. Tell users about /cost. People moderate their own consumption when the cost of a task is visible while they run it.

What to do with the first 90 days of data

Once real consumption starts, the Consumption tab answers the questions a budget owner will ask. Which groups drive spend. Which individual users are outliers. Which service, Cowork or Work IQ API, accounts for the volume. Active users in these reports means users who generated usage in the period, not everyone covered by the policy, so adoption and cost are two different lines to read side by side.

With a quarter of that data you can do the arithmetic that was guesswork in October: whether observed monthly consumption justifies a 25,000-credit capacity pack, whether annual volume clears the threshold where a pre-purchase tier beats the meter, and whether the per-user cap you picked is throttling people doing useful work or catching the ones who are not. Adjust the caps, then decide on prepayment. In that order.