Copilot Credits: What Changes on 1 December, and for Whom

From 1 December 2026, new Microsoft 365 Copilot Business licences bought through CSP arrive with usage-based billing enabled and a preset 4,000 Copilot Credits per user per month. Two lines in Microsoft's documentation decide whether that reaches you: the change covers Copilot Business only, not Microsoft 365 Copilot (Enterprise), and it is initially not available in eleven markets, the Netherlands and Belgium among them. Most readers here fail both filters, which is less reassuring than it sounds.

If you hold the Copilot estate for 250 to 5,000 people, as IT manager, informatiemanager, IT director or security officer, your question is narrower than the checklists assume: which of two risk shapes is yours. Crux Digits is a specialist AI supplier working next to your ICT partner. We do not sell infrastructure, service desks, networks or hosting, so what concerns us is not the invoice. It is that a supplier's purchase flow can set a default inside your AI governance that never reaches the person who owns it.

What exactly changes on 1 December 2026?

Microsoft's Partner Center documentation states that new Microsoft 365 Copilot Business licenses purchased through the Cloud Solution Provider (CSP) program include usage-based billing by default. There is no opt-in step: the page says plainly that at launch there is no separate step to explicitly opt in. Nine commercial B-SKUs are in scope, covering the Copilot Business add-on and several Business Basic, Standard and Premium bundles with Copilot. The scope also excludes education, nonprofit and government community cloud (GCC) low.

The preset numbers matter because they are what you inherit if nobody touches them. The default spending policy carries a per-user monthly limit of 4,000 credits and a tenant limit of 1,200,000 credits. The date moved: Microsoft gives 1 December 2026 as the updated effective date, previously communicated as 2 November. Partner write-ups from early October still carry the old date, so check which one your checklist assumes. The same announcement names the eleven markets where the change is initially unavailable: Australia, Belgium, Brazil, France, Germany, India, Italy, Korea, the Netherlands, Poland and Spain.

Does it apply to you? Two filters, and most Dutch readers fail both

This is the first fact to establish and the one almost every write-up reaches second. The scope section of the Partner Center page runs to three bullets, and the first settles it: Copilot Business (B-SKUs) only, and Microsoft 365 Copilot (Enterprise) is not in scope. Copilot Business is the add-on sold alongside the Microsoft 365 Business family: Business Basic, Standard and Premium. Those plans cap at 300 users, so past about 300 people you cannot be on them across the board at all, and below that line you may well be, which is the case to check first. Run Copilot on E3 or E5 and you are, by Microsoft's own definition, outside this change.

We are not the first to say so. EPC Group's spending-policy playbook is the most thorough of the English write-ups on the mechanics, and Universal Cloud made the scope point in September and carries the market exclusion too. What no write-up assembles is the other half: if the default is not your event, the one-time activation is, and nothing in those checklists tells you what it hands over. The rest of this post is that half.

There is one honest exception, and at this headcount it is common rather than exotic. Scope is per tenant, not per company. Organisations in the 250 to 5,000 band frequently hold more than one tenant: a recently acquired subsidiary still on Business Premium, a foreign branch set up separately. Those tenants are in scope by SKU while the parent is not. For tenants in the Netherlands or Belgium the default is deferred either way, so the SKU answer tells you what happens when the rollout reaches your market, not what happens on 1 December. Check per tenant and per CSP agreement, not per logo on the building.

If nothing switches on, where does the risk sit?

For the enterprise licence the model is gated rather than default-on. Microsoft's setup documentation describes activating the default spending policy as the step that activates the AI experiences, like Cowork, that are gated by usage-based billing. Before that, the metered services do not run. After it, they do.

That makes the activation itself the whole control, and it is a single click performed once, usually by whoever holds the privileged role when the first request for Cowork or Code arrives. Nothing turned itself on, which is exactly why nobody scheduled the decision. A change that waits for a human is the one that gets made in a hurry by someone who was asked to unblock a colleague.

What does one Activate click actually delegate?

Three decisions that keep applying, none of which announces itself as a decision. The first is scope. Microsoft's management documentation states that All users is selected by default for a spending policy, and the setup flow says the default setup targets your entire organization and all users. Activating to unblock one department enables the metered services for everyone unless you first switch to specific security groups.

The second is budget. The policy offers a choice between an unlimited and a limited monthly budget, and the per-user limit is presented as optional. Microsoft's own guidance recommends at least 2,000 credits per user per month and tells you to set it to prevent runaway spending. An optional field with that warning attached to it is a field to fill in.

The third is billing identity, and it is the one with consequences outside Copilot. Credits are billed to an Azure subscription you select, and the overview page's requirement is simply to connect an Azure subscription to support billing. If the person activating has no Azure subscription available, the setup documentation says the system automatically creates a subscription using the billing account linked in the Microsoft 365 admin center. That is a new Azure subscription appearing outside whatever landing-zone, naming and tagging conventions your estate runs on, created as a side effect of a licensing step.

Now put the roles next to it. Activating the default policy requires a Global administrator or a Billing administrator. An AI administrator or License administrator can edit limits, alerts and billing methods but cannot create policies. In a Dutch mid-market estate those two roles very often sit with the ICT partner or the CSP reseller, who holds the tenant. The person who can press Activate is therefore frequently not the person who owns the AI risk it opens, which is the seam we describe in our ICT partner says they do AI too. Where the invoice should land once it exists is a separate question, and we worked through it in FinOps for AI.

Why is auto-apply new services a governance setting, not a billing one?

Because it admits capabilities, not just costs. Microsoft's documentation says the Auto-apply new services toggle is selected by default, and that with it on, newly supported Copilot services and agents are automatically added to the policy as they become available. With it off, administrators must review and add each new service themselves.

The list it governs today is short and specific: Cowork, advanced work in SharePoint, advanced work in OneDrive, the Work IQ API, Copilot Managed Runtime, Teams Phone Agent and Code. Microsoft says on the same page that more will be added over time. So if your AI policy, your DPIA scope or your Article 4 literacy plan was written against a named set of Copilot capabilities, a toggle that is on by default widens that set without passing your intake. Autopilot makes the point concrete: Microsoft positions it as a persistent, proactive agent that carries on working when the user is not. That is not the same risk object as Copilot in Word, and it should not enter a tenant on the same approval.

This is adjacent to, but not the same as, the problem of an AI system whose behaviour changes without a release, which we covered in AI change management. There the change originates with you. Here it originates with the supplier, and the setting that decides whether you get a review is one your own admin turned on by accepting a default.

What can you turn off, and what can you not?

Less than you would assume, and the asymmetry is stated in Microsoft's own partner documentation. Usage-based billing cannot be fully turned off once it is configured. Setting a limit to zero stops further spend, and deleting the policy is the only way to stop spend entirely. Before configuration nothing runs; after it, the off switch is a limit or a deletion rather than a toggle.

The enforcement behaviour is worth knowing precisely, because it is often described loosely. When users hit their limit they lose access to the agents and services for the rest of the month until credits reset on the first of the following month. Alerts to administrators and users are notifications at a threshold, not enforcement. So a limit is a hard stop on access, and the alerts stop nothing at all.

Three inconsistencies in the same documentation are worth putting in front of your supplier. Upgrades to a UBB-enabled SKU do not automatically get the Azure artefacts or a spending policy, so a tenant can hold the licence without the billing plumbing. And seats added through the Partner Center portal enable usage-based billing with default values, while seat updates made through the Partner Center API do not. Two colleagues buying the same ten seats two different ways produce two differently configured tenants. The meter itself is also described three ways: the admin overview page lists seven services, the Partner Center scope bullet names three (Copilot Cowork, Work IQ APIs and GitHub Copilot Harness, the last on no other list), and the licensing page names a third, which includes Autopilot. Ask which list your supplier works from.

What should an IT manager do before 1 December?

Five things, in this order. Establish the Copilot SKU per tenant, including subsidiaries and anything acquired in the last two years, and write the answer down rather than remembering it. Ask your ICT partner or CSP in writing whether new orders will arrive with usage-based billing enabled, at what limits, and who currently holds Global administrator and Billing administrator on each tenant.

Then decide the activation question before the first Cowork or Code request arrives, not in the ticket that asks for it: who may activate, with which scope, which budget, and which Azure subscription. Turn off auto-apply new services for the first two quarters if you have an AI intake worth protecting, which is EPC Group's recommendation for regulated organisations and ours for anyone with a DPIA that names capabilities. And set the per-user limit even though the field is optional.

If this is going into a contract rather than a console, the clauses that carry it are the same ones we set out in updating an existing contract for AI. Our Microsoft Copilot implementation page covers the permissions, oversharing and rollout work underneath all of this, and what a build of your own costs is set out in custom AI development cost.

Last updated 22 October 2026. The Microsoft pages cited here carry document dates between 30 September and 13 October 2026, and on two of them Microsoft states that the list of metered services will grow and that some described features are not yet released. Check the scope table yourself before acting on any checklist, including this one.

Frequently asked questions