The spec was reverse-engineered from a deal that already happened
When intake gets bypassed, requirements get written backward to fit a signed deal. That is not sourcing. Here is how to run the renewal properly even when the first buy was not.
You already know this ticket. A team found a tool, ran it on a corporate card for two or three billing cycles, and the spend crossed whatever threshold trips a review. Now it lands on your desk with a note that reads like a formality: please formalise the vendor relationship. Attached is a one page requirements list. You read it and something feels off. Every line matches the product they are already using. The seat tiers match the invoice. The integrations match the tool. This is not a specification of a need. It is a description of a purchase, written afterward, to make the purchase look like it was chosen.
This is the quiet cousin of the intake ticket that names the vendor instead of the problem. There the decision was made before you saw it. Here the money moved before you saw it. Procurement is not being asked to source. It is being asked to sign a receipt and call it a process.
Why the backward spec exists
Start with the honest version of the team's motive, because it is not malice. A card purchase is fast. Intake is slow, or is perceived to be slow, which for the buyer's calendar is the same thing. Someone had a problem in Q1, found a tool by Thursday, expensed it by Friday, and solved the problem. The tool worked. Nine months later the annual spend is real, finance flags it, and the team is asked to bring it into the fold. At that point the requirement is not a hypothesis anymore. It is a habit. The people writing the spec cannot easily imagine the need without the tool that already fills it, so they describe the tool and call it the need.
That is the trap. A requirement written from a working tool inherits every incidental feature of that tool as if it were mandatory. The screen colour becomes a line item. The specific integration becomes non negotiable. This is exactly the pathology we describe in the requirement written to fit the incumbent, except the incumbent has only existed for three months and was never competed.
Why it persists past the first invoice
It persists because the formalisation looks like closure. Everyone wants the ticket shut. Finance wants the card spend converted to a proper contract with a purchase order behind it. The team wants to keep the tool they like. You want the governance box ticked. All three incentives point at one outcome: sign a paper contract for the thing that is already running, at roughly the price that is already being paid, and file it.
The problem is that a card buy almost never carries the terms a formal agreement should. No committed discount for the commitment you are now making. No price protection on renewal. Often no security review, which surfaces later as its own timeline reset, the pattern in the spec that skipped compliance. So the formalisation does not just miss a negotiation. It locks in the list price the team was paying on a card, plus a multi year commitment, and dresses it up as procurement having done its job.
Surfacing the buy before it hardens
The first platform motion is visibility, and it runs before the formalisation ticket ever arrives. Spend visibility ingests the card and invoice data and surfaces off-process purchases as they cross materiality, not nine months later. The same view catches when two teams are quietly running versions of the same tool, which is the shadow IT and duplicate tool problem in its native habitat. If you see the card spend at month two instead of month twelve, you are no longer formalising a habit. You are reviewing a young purchase with room to change course.
Reconstructing the real requirement
Visibility tells you the buy happened. It does not tell you what the team actually needed, and that is the harder half. This is where Vera does the reconstruction. Instead of accepting the backward spec, Vera works from usage signals, the invoice line items, and whatever terms were accepted at signup to rebuild the underlying requirement: the job the team was trying to do, the volume they are actually consuming, and which of the tool's features are load bearing versus incidental. That separation is the whole game. It is the difference between a flat list where everything is mandatory, the failure mode in everything is mandatory so nothing is negotiable, and a ranked requirement you can trade against at renewal.
Because the reconstruction is anchored in real consumption rather than the team's memory, it survives the person who bought the tool moving on, which is its own recurring headache in the spec that became folklore. The requirement is rebuilt from data, not from a rolled-off requester's recollection.
Running the renewal the first buy skipped
With a real requirement and a benchmark, the formalisation stops being a receipt and becomes a renewal you can run. The card rate goes against comparable closed deals so you know whether the team has been paying list, and by how much. The signup terms get decoded so you can see what the paper never protected, the kind of read described in decoding any contract. Then the target position and the missing terms, price protection, commitment discount, exit rights, go into a brief the team and finance can both read. The first buy was not sourcing. The renewal can be.
What this does not solve
Be clear about the boundary. The platform can surface the off-process spend, reconstruct the requirement, and hand you a benchmarked renewal position. It cannot undo a commitment the team already signed at signup, and some card purchases carry auto renewing annual terms that bind you before you ever saw them. It cannot make a team give up a tool they genuinely rely on, nor should governance be about that. And it cannot fix the cultural reason the card got used in the first place, which is that intake felt slower than a checkout page. If the review path stays slow, the next backward spec is already being written. The tool shortens the recovery. Making intake fast enough that people do not route around it is your work, not the platform's.
What the platform does change is the ending. An off-process buy no longer has to become a rubber stamped receipt. It becomes a renewal you run with a real requirement, a market price, and the terms the card never captured. The first purchase was not sourcing. The next one can be.
Fredrik has spent more than twenty years in enterprise software, with time at Oracle, IBM, SAP, and Salesforce before moving to the buy side. He structured and priced the kind of large agreements most buyers only see once or twice in a career, which taught him where the leverage sits and how far a vendor will actually move. He started VendorBenchmark to hand that knowledge to every sourcing team.
