How Much of Your Quoted Saving Is Actually Bankable

A modeled saving of $171,552 a year looked real until you asked how much of it could show up on the next invoice. The answer was close to zero.

A consultant can quote you a big annual number and be telling the truth about the model while still being wrong about your invoice. The two are not the same thing, and the gap between them is where most license savings quietly die. This article is about that gap, and about the one question that closes it.

The number that looked like a win

On a roughly 1,000-user estate, a like-for-like license optimization modeled an annual saving of about $171,552. That is a real figure, computed per user and then checked across the whole estate. It is the kind of number that ends up on a slide with a green arrow next to it.

Then we traced where it actually came from, and the slide got less comfortable. About $123,144 of that $171,552, more than seventy percent, rested on design roles the deployment package does not ship. The model priced those users as if a cheaper, purpose-built role were already live. It was not. It was designed, costed, and approved in principle, but it had not been built, shipped, or assigned to anyone.

Put differently, 179 of the 252 users the model counted as "cheaper" were priced on roles that did not yet exist in the environment. A user might be modeled at the Team Member price while the access they actually hold still requires a full Finance or Operations tier. The model is describing the future. The invoice describes the present. Until the two meet, the price does not move.

Why the realizable saving was near zero

Here is the part that trips up buyers, and sometimes sellers. You cannot bank a lower price while a user still holds the more expensive access.

Licensing in Dynamics 365 Finance and Supply Chain follows the highest requirement a user can reach. If someone keeps a privilege that demands a Finance license, that user costs a Finance license, no matter how elegant the cheaper role you have drawn up for them. The cheaper role only counts once two things happen in order. First, the new, cheaper role is actually built and assigned. Second, the old, more expensive access is revoked. Design, deploy, revoke, and only then does the meter drop.

Because the 179 users had neither the new role assigned nor the old access removed, the realizable saving on the next invoice was close to $0. Not because the model was dishonest, but because the model was pricing a destination while the users were still standing at the origin. Every dollar of that $123,144 was contingent on a revocation step that had not shipped.

The distinction that tells you what is real

Not all savings behave this way. The useful test is to ask what each dollar depends on, and savings split cleanly into two kinds.

The first kind comes from removing a license driver. You drop an unused privilege, strip an attach license nobody needs, or re-route a process so it enters through a cheaper point. The moment that package lands, the requirement is gone, and the price follows immediately. There is no second step. Removing the driver is the whole move. These savings ship the day the package is deployed.

The second kind comes from planned downgrades to cheaper roles. The user is meant to move from an expensive tier to a modest one, but only after the modest role is built and the expensive access is taken away. These savings are real in the model and absent from the invoice until that build-and-revoke sequence completes, in order, with sign-off.

Our $171,552 was mostly the second kind. The small remainder that was the first kind was the only part you could count on at deployment. That is why "how big is the saving" is the wrong first question. The right first question is "which kind of saving is this, and what has to ship before it counts."

The question to ask about any quoted number

So when someone hands you a savings figure, ask them to split it:

"How much of this is realizable on the next invoice, and how much is sitting on roles you have not shipped and access you have not revoked yet?"

A consultancy that knows its own numbers can answer that on the spot. It can show you the portion that removes a driver today and the portion that waits on a downgrade sequence, and it can show you the sequence. A consultancy that cannot answer it is quoting you a model and calling it a result.

We would rather tell you that $123,144 of a $171,552 model is parked behind work you have not done yet than let you take the full number to your CFO and miss it by seventy percent next quarter. The honest number is smaller on the first slide and far more survivable on the invoice. That is the trade we will make every time, because the saving that survives contact with your invoice is the only saving worth quoting.

This piece sits alongside a few others worth reading together. One covers what actually puts money on the invoice. One treats revocation as a sign-off list rather than an afterthought. One draws the line between a design as-designed and a package as-shipped. This article is the narrow case that connects them: the specific distance between a modeled saving and a bankable one, and why that distance is usually revocation.

Frequently asked questions