Microsoft 365 licensing: the rules that decide your bill

Microsoft 365 licensing is not a price list problem. The plan comparison tables are the easy part, published by Microsoft and copied by every reseller, and they are not where organisations lose money. The losses come from a handful of structural rules about how licences attach to services, to users and to data, and those rules live in documents nobody reads. This page is the hub for the licensing decisions on this site: the rules first, then the three uplift questions worth modelling, then what happens when a licence goes away.

If you already know which question you are answering, jump straight to it: the Purview cliff edges are in what Microsoft Purview actually costs, the enterprise uplift maths is in Microsoft 365 E3 vs E5, and the identity tier is in Entra ID P1 vs P2.

The rule that beats every comparison table

The most useful sentence in Microsoft 365 licensing is not in a plan comparison. It is in the tenant-level services licensing guidance, and it reads: Some tenant services aren’t currently capable of limiting benefits to specific users.

Read that twice, because it inverts how most people reason about compliance. The intuitive model is that a feature you have not paid for does not work. The documented model is different. The same guidance defines a tenant-level service as one that is activated in part or in full for all users in the tenant, and then states plainly that Appropriate subscription licenses are required for customer use of online services.

Put those together and the actual rule appears: for a whole class of services, technical enforcement and licensing requirement are not the same thing. The feature works for users who are not licensed for it. You are still required to licence them. No portal will warn you, no policy will fail, and the first time it surfaces is a true-up or an audit.

So the correct first question about any capability is not “does it work” but “is this a tenant-level service, and if so who benefits from it”. A data loss prevention policy, a retention policy, an audit configuration: these are applied to the tenant. If the benefit reaches a user, that user needs the licence whether or not anything ever asked for it. This is the mechanism behind almost every unpleasant surprise in a compliance licensing review, and it is why the Purview page on this site is written around cliff edges rather than features.

Add-ons attach to a base licence, and the qualifying list is wider than you think

Almost every licensing decision after year one is really an add-on decision. The base plan is rarely reopened; what changes is which add-on gets attached to which subset of users.

Two things about add-ons catch people out. The first is that an add-on is worthless without a qualifying base licence on the same user, so an add-on budget is really two budgets if the population is not already on a qualifying plan. The second, and the expensive one, is that the qualifying list is usually broader than the marketing implies. Assuming it is narrow is how an uplift gets budgeted that was never required.

The paid Copilot add-on is the clearest current example. Every third-party guide reduces the prerequisite to E3, E5 or Business Premium. The documentation does not. The qualifying list runs through Microsoft 365 E7, E5, E3, F1 and F3; Office 365 E5, E3, E1 and F3; the standalone Teams, Exchange, SharePoint and OneDrive plans, down to the Kiosk tiers; the Planner and Project plans; both Visio plans; and Microsoft Clipchamp. If somebody has told you a population on a cheap standalone plan must be uplifted to E3 before it can have the add-on, that is a reseller simplification rather than a rule.

The pattern repeats across the estate, so the discipline is the same every time: before you budget an uplift to enable an add-on, read the add-on’s own prerequisite list rather than the plan comparison. The two are written by different teams for different purposes, and only one of them is a licensing statement.

The three Microsoft 365 licensing questions worth modelling

Most licensing reviews try to answer everything at once and produce a spreadsheet nobody trusts. Three questions carry almost all of the money, and each gets its own page here because each needs its own maths.

Endpoint add-ons follow the same shape and are worth a fourth look if you manage devices. The arithmetic for Endpoint Privilege Management is a compact worked example of an add-on whose price only makes sense against the cost of the thing it replaces, which is the only frame in which any of these decisions can be answered honestly.

Assignment is where licensing becomes an operations problem

A licence bought and not assigned is a pure loss. A licence assigned two different ways is a support ticket with no error message. Assignment has two models and they interact badly unless you pick one deliberately and hold the line.

Direct assignment is per user and obvious. Group-based licensing assigns to a group and lets membership drive it, which is the only model that scales and the only model that fails invisibly. Microsoft names the failure classes explicitly: insufficient licenses, conflicting service plans, missing dependencies, proxy address issues, and usage location problems. Every one of those produces a user who looks licensed in the group and is not licensed on the account.

Three of those are worth naming properly. Usage location is a property on the user object, and a licence containing a service plan that is not available in that country will not apply, which is how a new starter recorded against the wrong office ends up without a mailbox. Missing dependencies bite when a service plan needs another service plan that the assigned SKU does not include, so the licence applies and one workload inside it quietly does not. Insufficient licences is the worst of the three, because it is silent and order dependent: the group has more members than you hold licences for, and which members miss out is not a decision you made.

The permissions are narrower than people assume, too. The documentation states you must be at least a Groups Administrator, License Administrator, or User Administrator to assign licenses, which is a useful line to have at hand when somebody asks why the service desk cannot do it. The mechanics and the full error list are in assign or unassign licences to a group, and that error list is the first place to look when a user is mysteriously unlicensed.

The operational rule that follows is simple and worth enforcing: pick group-based licensing, use it for everything, and never mix it with direct assignment for the same product. A user holding both is not an error state anybody will tell you about. It is an error state you discover when you remove them from the group and nothing at all changes.

The granularity almost nobody uses

A licence is not one thing. It is a bundle of service plans, and the assignment interface lets you switch them individually. In the admin centre the licence assignment for a group is reached from the Billing > Licenses page, and the control is the one most administrators scroll past: To assign or remove access to specific items, select Turn apps and services on or off.

That control is the answer to a problem the first section of this page creates. If a tenant-level capability can benefit users you have not licensed, and you have not yet built the governance for it, then the safe position is not to buy a smaller SKU. It is to hold the SKU and leave the service plan off until the governance exists. Turning a service plan off is a licensing decision you can reverse in an afternoon; buying the wrong SKU is one you reverse at renewal.

Two cautions come with it. The first is that service plans have dependencies on each other, which is exactly the missing dependencies error class from the group licensing list: turn off a plan that another enabled plan needs, and the second one fails without saying why. The symptom is one workload inside an otherwise healthy licence quietly not working, and it looks nothing like a licensing fault, which is why it usually gets escalated to the wrong team first.

The second is that this granularity is a per-assignment setting, so if you use it you have now made the assignment itself carry information. A group called All staff E3 that silently has two service plans disabled is a trap for whoever inherits it. If you switch plans off, put the reason in the group description, because the admin centre will not remember it for you and the next person will assume the default.

Used deliberately, this is the most underrated control in Microsoft 365 licensing. It lets the licence position and the rollout position be different things, which is what you want during any staged deployment, and it means the answer to “can we buy it before we are ready to run it” is yes.

Names are the other reason licensing scripts break

The same product has three different identities depending on where you look, and this is a licensing problem disguised as a scripting problem. In Microsoft’s own words, in the product names and service plan identifiers reference: When managing licenses in the Azure portal or the Microsoft 365 admin center, you see product names that look something like Office 365 E3. When you use PowerShell v1.0 cmdlets, the same product is identified using a specific but less friendly name: ENTERPRISEPACK. With Graph it becomes a GUID again. If you have ever written a licensing report that worked in one tenant and not another, this is usually why.

That page also carries the most honest caveat in the licensing documentation set, which is that its contents are accurate only as of the date when this article was last updated. Treat it as a dated snapshot rather than a specification. The live answer for your tenant is whatever Graph returns from your own subscribed SKUs, and that is a two line query.

1# Ask the tenant rather than the documentation. Returns the SKU part numbers you
2# actually own, with consumed against prepaid units, which is the pair of numbers
3# that decides the renewal conversation.
4Connect-MgGraph -Scopes "Organization.Read.All"
5Get-MgSubscribedSku | Select-Object SkuPartNumber, ConsumedUnits -ExpandProperty PrepaidUnits

Reclaiming a licence is a data decision, not a cost decision

The most expensive licensing mistake is not overbuying. It is reclaiming a licence without reading what reclaiming does, and this is the part of Microsoft 365 licensing that has a clock attached to it.

Microsoft’s guidance on removing a licence from a former employee states it plainly: When you remove a license, that user’s data is held for 30 days. You can access the data, or restore the account if need be. After 30 days, the user’s content (except for documents stored in SharePoint) is permanently deleted from Microsoft 365 and can’t be recovered.

Three consequences follow, and they point in different directions. First, a leaver process that harvests licences on the last day starts a 30 day timer on the mailbox, and a request from legal on day 40 cannot be satisfied at any price. Second, the SharePoint exception cuts the other way: documents in SharePoint are explicitly outside that deletion, so an assumption that removing the licence cleaned everything up is wrong in the opposite direction.

Third, and this is the one that catches compliance teams, the same page states that Before you remove a license, you must remove all holds for the user, and that if the mailbox needs to be reachable by people with eDiscovery permissions for legal reasons then it must be assigned an Exchange Online Plan 2 license (or an Exchange Online Plan 1 license with an Exchange Online Archiving add-on license) so that a hold can be applied to the mailbox before it’s deleted. Preserving a leaver’s mailbox properly costs a licence. It is a smaller licence than the one you are reclaiming, but it is not zero, and no leaver checklist I have seen budgets for it.

Failure modes, licensing edition

What I would do differently

I have not run a true-up for a large estate and there are no figures in this post that came from one. My tenant is a lab with no users to licence. What follows is judgement about the shape of the problem rather than a measured result, and the documentation above is where every fact in it came from.

I would stop treating licensing as a procurement exercise that happens annually and start treating it as configuration with a price attached. The tenant-level services rule forces this: if a capability can benefit users who are not licensed for it, then the licence position changes every time somebody switches something on. That makes it a change control question rather than a renewal question, and the right place to record it is next to the policy that enabled it, not in a spreadsheet somebody opens in March.

I would build the licence position from Graph rather than from the admin centre. The admin centre tells you what you bought. Graph tells you what is consumed, by whom, and through which assignment path, and it is the only view that distinguishes a group-assigned licence from a direct one. Anything that cannot be reproduced by a script will drift, and drift in licensing is money.

I would model every uplift against the cost of the thing it replaces and never against a feature list. The E5 case is not thirty features, it is a handful of capabilities you would otherwise buy from somebody else, and if the organisation will not actually operate them then the uplift is a donation. The same test decides every add-on linked from this page.

I would put the leaver process in the same review as the licence budget, because they are the same decision seen from two ends. Harvesting licences aggressively is the cheapest thing you can do until the month it is the most expensive thing you have ever done.

And I would write down, once, which population sits on which plan and why. Not a list of SKUs: a paragraph per population explaining the reasoning. Licensing reviews go wrong because the reasoning was never recorded, so each review restarts from the prices rather than from what actually changed since the last one.

Last verified: 30 September 2026