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.
PART TWO
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.
app.isvcosell.com/spend
Off-process card spend surfaces in the estate view before anyone files a formalisation ticket.
THE SAME JOB, TWICE
TODAY, BY HAND
Pull the card statements and expense exports to find how long the tool has been running and at what monthly rate
Interview the team to separate what they actually need from what the tool happens to do
Search email and shared drives for any order confirmation or terms accepted at signup
Draft a real requirement and a target price from scratch, with no benchmark to anchor it
Roughly 14 hours, spread across two to three weeks and three people
WITH ISVCOSELL
Open the spend view and let it group the off-process charges into a single vendor line with tenure and run rate
Ask ISVCOSELL to reconstruct the underlying requirement from usage, invoices, and the signup terms on file
Pull the matching benchmark to see where the card rate sits against comparable closed deals
Generate the renewal brief with the target position and the terms the card buy never captured
About 40 minutes of your attention
What changes: 14 hours of email archaeology and cold drafting becomes about 40 minutes of review. For a procurement team formalising even three or four card buys a quarter, that is roughly 150 hours a year returned, and every one of those renewals now starts from a benchmarked position instead of the card price.
PART THREE
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.
"A requirement written from a working tool treats every incidental feature of that tool as mandatory."
PART FOUR
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 ISVCOSELL does the reconstruction. Instead of accepting the backward spec, ISVCOSELL 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.
app.isvcosell.com/ISVCOSELL/requirement
ISVCOSELL rebuilds the real requirement from usage and invoices, then anchors the target against comparable closed deals.
PART FIVE
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.
1 Catch the spend early. Spend visibility surfaces off-process card purchases as they cross materiality, so you review a young buy instead of formalising a nine month habit.
2 Do not inherit the backward spec. The requirement attached to a formalisation ticket describes the tool, not the need. Set it aside before you cost it.
3 Reconstruct from usage, not memory. ISVCOSELL rebuilds the real requirement from consumption, invoices, and signup terms, separating load bearing features from incidental ones.
4 Anchor the card rate to market. Benchmark the price the team has been paying so the renewal target is a number, not the invoice.
5 Capture the terms the card buy skipped. Price protection, commitment discount, exit rights. A formalisation without these just locks in the list price on a longer contract.
HONEST LIMITS
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.
About the author
Fredrik Filipsson, Cofounder, ISVCOSELL
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 ISVCOSELL to hand that knowledge to every sourcing team.
More posts by Fredrik Connect on LinkedIn →
See it in the product
How benchmarking works → Browse the use cases → Every feature → Calculate your time saved →
FREE TRIAL · FULL PLATFORM · NO CARD REQUIRED
Turn an off-process buy into a renewal you can actually run
The free trial opens the benchmarking database, 1,483 vendors deep, plus the negotiation guides, playbooks, and talking points for your own renewals. No card needed, a corporate email is all it takes.
Start your free trial → Or decode a contract free, no account
Free for 30 days, no card needed. Your data stays isolated at the database, and you can export or delete it any time.
Watch it in action
Browse the full demo library →
V ISVCOSELL
A ISVCOSELL product · © 2026
PLATFORM Benchmarking Negotiations Contract management AI workflows Document search Renewal calendar
PRODUCT Use cases Features Security Pricing Deployment options About
RESOURCES Getting started ROI calculator Agent protocol FAQ Blog Request access