The gap between reported value and actual value starts long before the negotiation table.
There is a number that appears in nearly every procurement review deck. It sits in a clean table, usually in the second or third slide, under a header like Value Delivered or Cost Avoidance Summary. It represents the gap between what a vendor first quoted and what your company ultimately paid. It returns value to the organization, contributes to the team's operating cost, and validates sourcing strategy.
It is also, in most cases, a fiction.
Not fraud. Not incompetence. A structural fiction: one that everyone involved understands implicitly and that no one has much incentive to dismantle. The vendor knows it. The procurement team knows it. The CFO suspects it and accepts it anyway because the alternative is a conversation no one has a framework for.
This is an article about that conversation.
The Metric That Runs on Phantom Data
The standard unit of procurement success is savings. Specifically, it is the difference between a vendor's opening price and the price you signed. If a vendor quotes $400,000 and you negotiate to $340,000, your procurement team reports $60,000 in savings. That number goes into a dashboard. It gets compared to prior years. It informs the team's operating cost and resource allocation.
Here is the problem: the $400,000 was never real.
Enterprise software pricing is not like commodity pricing, where a market rate exists independent of any particular buyer. It is relational pricing: which is a polite way of saying it is whatever the vendor believes you will pay, set high enough to create room for a negotiation that feels like a win. The opening quote is not an honest assessment of value. It is an anchor, deliberately placed. The discount is not a concession. It is a feature of the sales process, designed in advance, available to virtually every buyer who asks for it.
When you measure savings against that anchor, you are not measuring performance against reality. You are measuring performance against a number the vendor invented for you.
The scorecard is built on the other side's inputs. No one in finance would accept that logic in any other context.
How the Anchor Gets Set
To understand why this happens, you have to understand how enterprise software deals actually begin: not how procurement policy says they begin, but how they begin in practice.
A vendor's sales team identifies a target account. They research the organization, map the stakeholders, and find the person with the most acute pain: usually a business unit leader, a VP of Operations, a head of Finance, occasionally a CEO who attended a conference and saw a demo. They reach that person through a warm introduction, a well-timed cold email, or increasingly, a piece of content designed to make the pain feel urgent.
Then they run a process.
It is a good process. It has been refined over hundreds of deals. It involves discovery calls that feel like consultations, demos that show the product at its best, reference customers who are prepared to take calls, and a business case template the vendor helpfully provides. By the time a formal quote arrives, the business unit has already made a psychological decision. They have presented the solution internally. They have a champion on the vendor side. They have told their team this is the direction they are going.
At this point (and this is the critical moment), procurement gets involved.
They receive a scope that has already been defined. A vendor relationship that has already been built. A business unit that is already committed. And a quote that has been calibrated to all of the above.
The negotiation that follows is real, in the sense that words are exchanged and the number moves. But the leverage that would have produced a genuinely different outcome (a different scope, a different structure, a different vendor entirely) is gone. It evaporated the moment the business unit fell in love with the product before anyone asked what it should cost.
This is the car dealership problem. Everyone understands not to go for the test drive before you have negotiated the price. You check the invoice cost, you know your walk-away number, you arrive with a position. The test drive is how you confirm a decision you have already made on rational grounds, not how you make it. Enterprise software buyers do the test drive first. Every time.
Why This Persists: Five Structural Reasons
The natural question is why sophisticated organizations allow this to happen repeatedly. The answer is not negligence. It is that the system produces outcomes that are acceptable to everyone involved, and the true cost is distributed in ways that are difficult to see.
The savings metric rewards the symptom, not the cure. A procurement team that gets involved early (before the vendor quote, before the demo, before the business unit is committed) will produce deals that come in at or near fair value from the start. The opening quote will be lower because the vendor understands they are dealing with a prepared buyer. The final price will be close to the opening price because there was less room built in. Result: small reported savings. By the conventional metric, a poor performance. A procurement team that gets involved late (after the business unit is committed, after the vendor has run their full sales process) will negotiate from an inflated baseline and report large savings. Result: large reported savings. By the conventional metric, an excellent performance. The incentive structure selects for late engagement. This is not a management failure. It is a measurement failure.
The vendor's sales process is engineered to get commitment before scrutiny. Enterprise sales methodology is sophisticated and well-funded. Frameworks like MEDDIC, Challenger Sale, and Command of the Message are explicitly designed to establish economic justification, identify the decision-maker, and secure internal commitment before procurement introduces friction. The vendor sales team is trained, coached, and compensated to complete this sequence. The buying organization has no equivalent playbook. There is extensive literature on how to sell enterprise software. There is almost nothing on how to buy it.
The business unit believes it knows how to buy. Business unit leaders buy things in their personal lives. They have bought cars, negotiated leases, shopped for mortgages. They carry that intuition into software decisions and it fails them, because software is a categorically different commercial environment. The vendor has done this deal five hundred times. The buyer has done it once, maybe twice. The information asymmetry is not marginal: it is structural. But it is invisible to the person experiencing it, because competence in one commercial context feels like competence in all of them.
The counterfactual is unpublishable. The true savings from early procurement engagement cannot be reported, because they exist only as a comparison to a quote that was never made. If procurement is involved before the vendor knows how committed the business unit is, the vendor may never table the inflated number. The deal comes in clean. There is nothing to compare it to. The CFO sees a number, approves a budget, and the value of the process that produced that number is invisible. You cannot put a counterfactual in a savings report. So the work that prevents the problem goes unmeasured, and the work that responds to the problem gets all the credit.
The cost never aggregates into a crisis. Software overpayment is a chronic condition, not an acute one. Individual deals are too small to constitute a scandal. Auto-escalation clauses of eight to twelve percent compound quietly over multi-year terms. Shelfware accumulates gradually. By the time a portfolio is meaningfully oversized, the people who signed the original contracts have moved on, the vendor is deeply embedded, and switching costs exceed the cost of staying. So you renew. It is not a crisis. It is a slow tax. And like most slow taxes, it is easier to pay than to fight.
What It Actually Costs
The absence of a crisis does not mean the absence of cost. It means the cost is diffuse enough to absorb.
Consider what the inflated anchor produces over a typical software contract lifecycle. A deal signed at $340,000 against a fair market value of $280,000 (a gap of $60,000 in year one) carries that overrun forward. An eight percent annual escalation clause, standard in most enterprise software agreements, applies to the inflated base. By year three, the cumulative overpayment is not $60,000. It is substantially more, and the escalation continues.
Now consider that the average mid-size enterprise manages between forty and two hundred software contracts simultaneously. The overpayment is not one deal. It is a portfolio condition.
There is a second cost that does not appear on any invoice: the terms you did not get. Early engagement produces not just better pricing but better contracts (favorable termination rights, audit provisions, performance SLAs, data portability clauses, price protection on renewals). These are negotiating chips that are available before commitment and almost unavailable after it. The business value of a well-structured contract over a five-year term is real, and it is entirely invisible in a savings report.
The Conversation No One Is Having
The procurement profession is not unaware of this dynamic. Senior practitioners understand it. The phrase get procurement a seat at the table has been repeated at every sourcing conference for twenty years.
What the profession has not done is diagnose why that seat keeps not materializing, and build something that addresses the actual mechanism.
The standard prescription is organizational: get procurement involved earlier, change the policy, require sign-off before vendor engagement. This fails in practice for reasons that are also structural. There is no natural trigger in most organizations for this is now a procurement event. Projects begin as explorations, become evaluations, become commitments, and quietly become budget line items. By the time a formal process starts, the informal process has already concluded.
There is also a Catch-22 that no policy resolves: you need a price to build a budget case, and the only way to get a price is to talk to the vendor. The moment you talk to the vendor, you are in their process. There is no neutral mechanism for getting pricing information without initiating a sales relationship. So the business unit does what is rational given the available tools (they engage the vendor, get a number, build a case, get attached, and call procurement when the paperwork needs to be done).
The problem is not that people are making bad decisions. It is that they do not have the tools to make better ones before the leverage is gone.
A Framework for What Early Looks Like
If the goal is to recover leverage (not at the negotiation table, but before the vendor knows the deal is real), the intervention has to happen at three specific moments.
Before vendor contact: define the position. Before any vendor conversation begins, the buying team needs four things in writing: what problem they are actually solving, what success looks like in measurable terms, what they are willing to pay for that outcome, and what happens if they do not buy. Most organizations skip this entirely. The result is that the vendor's discovery process defines the scope, the vendor's business case template defines the value, and the buyer arrives at negotiation without a position. A written requirements definition, produced internally before any demo, changes the commercial dynamic. It signals a prepared buyer. Prepared buyers get different quotes.
Before commitment: do the test drive last. The sequence matters more than the participants. The organizational question (which team is involved) is less important than the order of operations. Price and terms should be negotiated, or at minimum anchored, before the business unit has publicly committed to a direction. Once commitment is visible (once the internal presentation has been made, once the champion relationship is established, once the team is excited), the negotiating position has already been conceded. Run the commercial process in parallel with the evaluation, not after it. Negotiate on a hypothetical before you negotiate on a decision.
Before signing: stress-test the exit. The most expensive clause in most software contracts is not the price. It is the absence of a defined exit. Switching costs (data migration, retraining, integration rebuilding) are the mechanism by which vendors convert a good deal into a permanent one. A contract that does not define termination rights, data portability, and transition assistance is a contract that prices in lock-in on the vendor's behalf. The question to ask before signing is not are we happy with the price. It is: what does it cost us to leave in year three, and have we negotiated terms that make that cost acceptable. If you cannot answer that question, you have not finished the deal.
The Reframe
The problem with how most organizations measure procurement is that it is a lagging indicator masquerading as a performance metric. Savings reported against an inflated opening quote tells you how well your team plays the game the vendor designed. It tells you nothing about whether you got a good deal.
A better measurement framework asks different questions:
Did we engage before the vendor knew we were committed? Did we produce a written position before the first demo? Did we negotiate in parallel with evaluation, not after it? Did we define the exit before we signed? Did we pay within the range of fair market value for what we actually needed?
These questions do not produce a savings number. They produce a process audit. That is harder to put in a slide deck. It is also a more honest account of whether your organization is managing software spend or just managing the appearance of it.
The vendor is very good at their job. They have a playbook, a process, and a team that executes it on every deal. The question is not whether you can out-negotiate them at the table. You probably cannot, not at that stage. The question is whether you show up prepared enough that the table never gets set on their terms.