Dynamics 365 licensing costs: what actually drives the bill

How Dynamics 365 is priced

Dynamics 365 is licensed per named user per month, by the functionality that user needs rather than by the size of the organisation. Microsoft's model distinguishes full users, who create and configure records across an application, from lighter access for people who only need to view information or participate in a limited way.

Where a person needs more than one application, base and attach pricing applies: the first application is licensed at the base rate and additional qualifying applications are added at a lower attach rate for that same user. Getting base and attach the wrong way round across a population is one of the most common causes of avoidable spend we see, because the higher-priced application should normally be the base.

On top of user licensing sit capacity items: database and file storage, and consumption-based services in the wider Power Platform and Azure estate. These are frequently forgotten in the business case and then appear as growth nobody planned for.

What inflates the bill

• Uniform licensing: everyone given the same full user licence because it was simpler at go-live than assessing roles.
• Leavers and dormant accounts still holding licences because deprovisioning is not tied to the joiners and leavers process.
• Base and attach applied in the wrong order across a mixed population.
• Applications bought during a programme for a phase that was later descoped, and never removed at renewal.
• Storage growth from audit logs, attachments and integration staging data that nobody owns.
• Renewal on autopilot, where last year's counts are rolled forward because the review window was missed.

None of these are pricing problems. They are governance problems that arrive as an invoice, which is why a licensing review that only compares rates rarely finds much.

Reviewing an estate properly

A defensible review starts with actual usage rather than the licence schedule. What we look for is the gap between entitlement and behaviour: users holding a full licence who only ever read, users sharing an account because provisioning was slow, applications with an assigned population and negligible activity.

That is then reconciled against roles, not against people. Roles are stable and can be governed. Individual assignment drifts within weeks of anyone leaving the process alone.

Finally, changes have to be timed against the agreement. Reductions generally take effect at renewal rather than immediately, so a review completed a month after renewal has largely wasted a year. Working backwards from the renewal date is the single most valuable planning step in the exercise.

Cutting cost without creating exposure

Reducing licence counts is easy. Reducing them without creating a compliance exposure requires knowing what each remaining user is actually permitted to do, particularly where automation, integration and reporting access users' data on their behalf.

Service accounts, Power Automate flows running under a user context and external portal access are the areas where organisations most often assume they are covered. They should be documented as part of the review rather than discovered during an audit.

Our view is that a licensing position should be as evidenced as a financial control: a current record of who holds what, why, and under which agreement, reviewed on a schedule rather than in response to a renewal notice.

What a healthy licensing position looks like

• Licence type mapped to role, with a named owner for each mapping.
• Deprovisioning tied to the leavers process, not to a periodic clean-up.
• Base and attach checked whenever a user gains or loses an application.
• Storage growth monitored with an owner, not discovered at renewal.
• A review completed in good time before the renewal window closes.