Dynamics 365 bills per user, over the union of everything that user's roles grant. A license is not a property a role owns, which means three of the most natural ways to reason about a redesign are all wrong at the same time.
On one estate, pricing roles at Microsoft's per-role SKU produced a bill of $1,218,300 a year. The actual Dynamics 365 bill for the same estate was $1,190,940. The $27,360 gap is not a discount or an error. It is the signature of a model that counts a dimension Microsoft does not charge for.
Where the money is actually decided
Dynamics 365 Finance & Supply Chain charges one seat per user. That seat is the highest license tier required by any privilege in any role the user holds. The tiers rank Full module above Activity above Team Members above None, and when a user needs more than one Full module, the first module is the base SKU and each additional module prices as a cheaper Attach SKU.
The input to that calculation is the user's complete privilege set, pooled across every role. Two roles, five roles, a custom role and three standard ones: Microsoft flattens them into one pile of privileges per person and prices the pile once. The invoice has a line per user. It has no line per role, because a role is never the thing being billed.
Why per-role thinking keeps producing wrong answers
Once you accept that the bill has no role dimension, three common moves collapse.
"Promote the redesign role by role, and skip any role that needs the same license as the one it replaces." This treats license parity between an old role and its replacement as evidence of no savings. It is a category error. Savings show up when a user stops needing a tier, and whether a user stops needing a tier depends on every other role they hold, not on a one-to-one comparison between a role and its successor. A replacement role that looks identical on license can still be the role that removes the last Full-tier privilege from thirty people once their other roles move.
"Exclude this license from this role so the users on it stop paying." Removing a license requirement from one role guarantees nothing. A user keeps paying for that tier if any other role they hold still carries a privilege that needs it. You can strip a role to the studs and watch the same users bill exactly as before, because their cost was never coming from that role.
"Price the estate by adding up each role's SKU." This is the $1,218,300 number. It overcounts because it bills a module every place it appears instead of once per person, and because it cannot see that Dynamics 365 resolves an "either app" privilege across all of a user's roles before deciding which single app to charge. Summing role SKUs is not a conservative estimate of the real bill. It is a different quantity that happens to be denominated in dollars.
The model that matches the invoice
The correct unit is the user, and the correct calculation is a minimum-cost set cover. Each privilege a user holds accepts one or more license options, so Microsoft's own export lists the options as an OR-set per privilege. The seat is the cheapest combination of licenses that satisfies every one of the user's privileges, pooled across all roles, priced as base plus Attach.
Built that way, the model reproduced Dynamics 365's own per-user cost for 935 of 945 users on one client, and matched exactly for all 176 holders of one heavily used role at $640,080 a year on both sides. The ten misses all shared a single role where Microsoft bills a Commerce license even though the user's SCM license already covers every privilege in it. The agreement is close enough to treat a divergence as a finding about Microsoft's billing, not noise in the model.
Minimum-cost cover matters more than it sounds. The naive version prices each privilege against the cheapest single license and adds them up, which is the union of module flags. On one estate that union priced 694 users as "cheaper than today" totaling $540,744, while the real minimum-cost cover found 252 users totaling $171,552. The $369,192 difference was never a saving. It was the union method inflating the baseline it was measured against.
We helped train clients to think this way
Our own report once printed a "seat required" value on a per-role row. Any competent IT manager reads a dollar-like figure next to a role as "this role costs this." The per-role mental model that breaks every promotion decision is partly a model we taught. The fix is to rename that column so it cannot be read as a price, and to index every dollar on the user.
Bottom line
A role cannot have a license, so any analysis whose unit is the role is answering a question Microsoft never asks. Decide promotion per user or per cohort of users who share the same before-and-after role set. Price the estate as a minimum-cost cover per user on the real base-plus-Attach bill. Treat per-role and per-privilege dollar figures as non-additive detail, never as a total. The moment a number is summed across roles, it has left the invoice behind.
Frequently asked questions
If a role has no license, why does Microsoft's tooling show a license per role?
It shows the highest tier any privilege in that role requires, as a convenience. That is a projection of a user-level quantity. It is useful for spotting what a role contributes, and misleading the instant it is summed or read as a bill.
Does removing a Full-module privilege from a role ever save money?
Only for users who do not reach that tier through any other role. The saving is real but conditional on the user's whole holding, which is why it must be computed per user.
Why does per-role pricing overstate rather than understate?
Because it bills shared modules once per role instead of once per user, and ignores that Dynamics 365 resolves multi-option privileges across all of a user's roles before charging a single app.