You Caught Your Vendor in a Lie. Here Is What You Do About It.

Your vendor’s sales team just lied to you, or came close enough that it doesn’t matter which. Before you decide what that means, answer one question first: did that claim actually change the decision you were making. Whether the problem is one person or the whole company comes second.

Don’t decide whether to trust them yet

Right now you are probably asking whether you can still trust this vendor. That makes sense, but it skips the question that actually matters first. A lie that never touched your business case, your architecture, or your contract terms is a different problem than a lie your implementation plan is built on. Measure the impact before you measure the trust.

Here is where these lies usually live. A rep tells you a router with a web login page is SD WAN. A homepage lists a customer logo that never signed anything meaningful. A roadmap feature gets promised in an email or on a call, never in the contract, because a promise that never reaches the contract cannot be enforced and never has to be admitted to later. Nobody has to be lying on purpose for this to happen. They just need you to accept the claim without checking whether you actually relied on it.

Ask these two questions first

First: Did the claim change your decision? Would knowing the truth up front have changed whether you shortlisted this vendor, your projected cost, your implementation plan, or your contract terms? If nothing you relied on shifts once the claim is corrected, the exposure is low no matter how annoying the lie is.

Second: Is this one person or the company? A rep freelancing a promise nobody at the company approved tells you something about that person. A claim that shows up the same way across sales conversations, the proposal, the website, and even an executive statement is a different signal. If it stays exactly the same after someone challenges it, that tells you something about the company. What the vendor does after you push back is usually more revealing than the original claim. A vendor that says the claim was wrong, corrects it in writing, and explains what changes is telling you something useful. A vendor that redefines the term, blames semantics, or just keeps repeating it is telling you something else entirely.

Put those two questions together and the response gets obvious.

• Harmless, and it never touched your decision: document it and move on.
• Company wide, but not material to this deal: treat it as a reason to check everything else that vendor tells you a little harder.
• Material, from one person: you have not lost the vendor yet, but you have real work to do below.
• Material, and the company stands behind it after being challenged: that is your strongest signal to walk.

If it mattered, run this before you decide anything else

1. Write down exactly what was claimed and by whom.
2. Identify what part of your decision relied on it, the cost model, the architecture, the timeline, the compliance posture.
3. Verify the real answer with someone at the vendor who is accountable for that area, not the person who made the claim.
4. Get the corrected version in writing before you proceed.
5. Recalculate your business case without the false assumption in it.
6. Ask what else you accepted from this vendor without independently checking it.

That last step matters more than it looks. One proven false claim is a reason to recheck the adjacent ones, not just the one you caught. If they exaggerated the implementation timeline, revisit your staffing assumptions. If they misstated a security certification, have someone competent verify it directly. If they overstated a customer reference, ask that customer what they actually run in production, not what the case study says. A discovered false claim does not just cost you that one fact. It removes your reason to assume adjacent claims were verified properly.

If the decision depends on it, put it in the contract

Whatever you decide, some things do not stay as a sales conversation. If your business case depends on a capability, a timeline, a certification, a support commitment, or a roadmap item, that goes in the contract as a requirement, not as collateral you took on faith. Implementation dates, required integrations, data handling terms, and termination rights belong in the same category. If it matters enough to influence your decision, it matters enough to be enforceable.

What happens if you skip this

Skip all of this and the failure shows up later, not now. A roadmap promise that never made the contract resurfaces at renewal, twelve to eighteen months out, when the feature still does not exist and the person who promised it is gone. By then it is your problem to explain internally, not theirs.

When you should walk

You have enough to walk when any of these are true.

1. The false claim materially influenced your vendor selection or your business case.
2. Leadership repeats or defends something you can demonstrate is false.
3. The vendor refuses to correct the claim in writing.
4. The vendor will not contractually stand behind a claim your decision depends on.
5. Multiple claims fail independent verification.
6. The explanation changes depending on who you ask.

When ITBroker runs a sourcing process, checking claims like these against the public record and the contract is part of the work, not an afterthought.

If a vendor relationship is what is testing your patience right now, here’s what changes when someone independent is checking the vendor’s claims instead of just you.

For the full breakdown of how vendors sort into harmless, one person, and company wide, and what buyers get wrong in the same conversation, Max walks through it in the Signed episode Playbook: Finding the Truth When Everyone Is Lying.

The claim you just caught is the easy part to see. The harder question is what else you took on faith from the same vendor, and whether your contract would survive someone actually testing it.

We’ll tell you if this deal is actually competitive. Get Started. No pitch. No prep. Just answers.