The requirement your stakeholder wrote as included ships as a paid module

Look at the requirements document from your last sourcing cycle. One line reads like a plain feature: single sign on, or advanced reporting, or SCIM provisioning, or an API rate above the entry ceiling. A stakeholder wrote it as a must have and moved on, and the intake absorbed it as part of the base product. Now go back and check what the market actually does with that line. In a material share of categories, the thing your stakeholder treated as included is exactly the capability vendors carve out as a premium tier, a security add on, or an enterprise SKU with its own list price. The requirement did not change. The commercial shape of it did, and nobody in the intake noticed.

This is the quiet gap between what a capability is and what it costs to buy. A feature can be real, shipping, and demoed in the sales call, and still sit behind a paywall you have not budgeted for. When the intake treats it as bundled, the budget you approve is built on a market that does not exist.

Why the assumption feels safe when it is not

The stakeholder is not careless. They are describing the outcome they need, and from where they sit the capability is table stakes. Everyone offers SSO in 2025, so why would it be a line item. The answer is that packaging is a pricing lever, not a feature statement. Vendors learned that the capabilities buyers assume are free are precisely the ones worth fencing, because a buyer who has already committed to the product will pay to unlock them rather than restart the evaluation.

So the requirement enters the intake at zero incremental cost, and the whole downstream process inherits that zero. The budget owner sees a total. The shortlist gets scoped against it. This is a cousin of the failure we described in the requirements document that collapses your shortlist to one: the flat list hides not just priority but price structure. Every line reads the same weight and the same cost, and neither is true.

How the gap survives all the way to signature

The assumption persists because nobody owns the seam between the requirement and the quote. The stakeholder owns the need. Procurement owns the negotiation. The budget was often set before either of them looked at a price sheet, the problem we unpacked in the budget number approved before anyone checked the market. By the time a quote arrives, the premium module is a separate line with its own multiplier, and the reaction in the room is surprise rather than negotiation. Surprise is the worst possible posture at the table, because it reads as a buyer who did not do the work.

The vendor, meanwhile, has priced this deliberately. The base tier is competitive precisely so the entry number benchmarks well, and the margin lives in the add ons your stakeholder assumed were included. You can lose on total cost while feeling like you won on the headline. This is not a trick unique to any one seller. It is standard packaging across the enterprise software market, which is why treating it as a villain misses the point. The failure is on the buy side, in an intake that never asked which requirements carry their own SKU.

The platform motion that prices the assumption

The fix is two moves, and both happen before you set the budget rather than after the quote lands. First, decode the requirement against how the market packages it. Contract and quote decoding reads each line and marks which capabilities sit in the base product and which live behind a paywall, tier, or add on across comparable vendors. That turns a flat requirements list into a priced structure. The stakeholder still gets their must have. It just arrives with an honest label.

Second, benchmark the flagged capability against closed deals so the label carries a real number. It is not enough to know that SSO is a paid module. You need to know what buyers of your size in your category actually paid to unlock it. Benchmarking against 500,000+ real closed transactions, drawn from the method we describe in how the benchmark library is built, gives you the paid range rather than the vendor's opening list. That is the difference between negotiating a known premium and reacting to a surprise one.

Together these two moves reset the budget on the market that exists. The stakeholder's requirement is preserved. The CFO sees a total that includes the line item the intake would otherwise have hidden. And when the quote arrives with the premium module broken out, nobody in the room is surprised, because the number was already in the budget and already benchmarked. If you want to test one quote fast without an account, the free price check is the shortest path to seeing whether a line sits above the paid range.

What this does not solve

Decoding tells you which requirements sit behind a paywall and what they cost. It does not tell you whether the capability is worth buying. A benchmarked module can still be a bad purchase if the underlying need was overstated, and no amount of pricing evidence rescues a requirement that should have been a nice to have. The intake discipline of separating genuine must haves from inherited assumptions is human work, and the platform sharpens it rather than replacing it.

It also cannot force a vendor to unbundle. Some packaging is fixed, and the module will remain a line item no matter how well you benchmark it. What changes is that you pay the market price for it with your eyes open, and you set a budget the market will honour. There is a further limit worth naming: packaging drifts. A capability bundled at signature can migrate to a paid tier at renewal, which is why the pricing question never fully closes and why watching the invoice against the contract stays part of the job long after the deal is signed. The platform removes the surprise. It does not remove the discipline.

Want to be updated when major licensing and pricing changes land? One analyst brief a week: the price rises, metric changes and audit campaigns that move software costs. Work email only.