- Approvals move when the request pre-answers four questions: total cost, overlap with owned tools, data and security posture, and who owns the renewal.
- Most rejections are process rejections: hidden costs, duplicate spend, unanswered security questions, or no owner.
- If you own the process: short intake form, rule-based routing, visible status, and reassign-not-reject.
- The approval should end in the contract repository with owner and renewal date attached, not in an email thread.
Getting a software purchase approved comes down to answering, in advance, the four questions the approver is paid to ask: what does it cost in total, what do we already own that overlaps, what happens to the data, and who owns the renewal decision next year.
Requests stall when those answers arrive one objection at a time; they move when the request arrives with the answers attached. This guide covers how approval processes typically work at mid-market companies, what a request package should contain, and how to design the process itself if you own it, so governance stops rogue purchases without becoming the reason people route around it.
How do software approval processes usually work?
Most mid-market companies route by spend threshold. The patterns are consistent: department heads approve small purchases within budget, IT and security review anything that touches company data regardless of price, finance signs off at a middle tier, and six-figure commitments go to the executive level, sometimes with two signatures. Formal reviews at the top tier commonly take weeks, not days, and that latency is exactly why people bypass the process with a corporate card and an apology.
What should a purchase request include?
A request that answers the approver’s questions before they’re asked:
- Total cost of ownership, not the stickerPer-seat price times realistic seats, implementation and add-ons, and the multi-year shape if there’s a term commitment. Finance approves numbers, not “about $30 a seat.”
- The overlap check, doneWhat existing tools cover part of this need, and why they’re insufficient. “We hold 200 seats of X, 60 unassigned” either kills your request or armors it, and both outcomes are cheaper than approval-then-discovery.
- Data and security basicsWhat data the tool touches, where it’s stored, SSO support, and the vendor’s security posture. Answering this proactively is the difference between a two-day security review and a three-week one.
- An owner and an exitWho owns this vendor relationship, when it renews, what the notice window is, and how you’d get the data out. Purchases without owners become next year’s zombie renewals.
Why do requests actually get rejected?
Rarely because the tool is bad. The recurring rejection reasons are process reasons: the spend overlaps something already owned, the true cost only emerged during review, security couldn’t get answers from the vendor, or nobody could say who would own the renewal. All four are preventable in the request package. There’s an organizational fix too: approvers who can only approve or reject will reject ambiguity. A process that supports reassigning a request (“this belongs in the data-tools budget, send it to that owner”) and FYI visibility for stakeholders who don’t need to sign converts dead-end rejections into routed decisions.
If you own the process: how do you keep it from being bypassed?
Make the sanctioned path faster than the workaround. Concretely:
One intake form, short
Ask only what routing needs: what, why, cost, data touched. Every extra field taxes compliance with the process.
Route by rules, not by reply-all
Thresholds and data-sensitivity determine who must approve; the requester shouldn’t need to know the org chart. Approvals in email threads are where accountability goes to die.
Show requesters their status
Half the shadow purchases we hear about started as “I submitted a request and never heard back.”
Connect approval to the contract
When a request is approved, its contract should flow into the repository automatically, with owner and renewal date already attached. That’s how the approval process feeds the renewal process instead of ending at yes. See how procurement intake works without a procurement team.
How do you make the business case for a tool the company doesn’t think it needs?
Anchor it to a cost the approver already believes in. Generic productivity claims lose to specific, checkable numbers: seats you can release elsewhere by consolidating, a renewal you can right-size with the data the tool provides, hours of a named process it removes. In License Logic’s interviews with 80 mid-market executives, 50% reported wasting 20% or more of license spend on unused seats; if your case touches spend visibility, waste you can already point to beats benefits you have to project. And pre-empt the security review: bring the vendor’s security documentation with the request, because that review, not the price discussion, is where software purchases go to wait. Our vendor security review checklist covers what to collect.
License Logic runs software requests through a short intake form with rule-based routing, then lands each approved request in the contract repository with its owner and renewal date attached, so approval feeds the renewal process instead of ending in an email thread.
Frequently asked questions
What spend thresholds should trigger higher approval?
There’s no universal number; the pattern that works is tiered: department budgets for small purchases, IT/security review for anything touching company data at any price, finance at a middle tier, and executive sign-off for six-figure commitments. Set the tiers so the common case (small, low-risk tools) moves in days.
How do we stop people from buying software on corporate cards?
Make the sanctioned path faster than the workaround and keep card visibility as the backstop. A short intake form with rule-based routing beats policy memos; card and ERP spend data then catches what still slips through, so the conversation is “we saw this, let’s route it properly” instead of an audit surprise.
What’s the fastest way through a security review?
Bring the vendor’s security documentation with the request: data handled, storage location, SSO support, subprocessors, and their security overview or questionnaire answers. Reviews stall on unanswered questions, not on hard ones.
Should every renewal go through the approval process again?
Not the full process, but renewals above a threshold or with changed terms deserve a lightweight re-check: current usage versus seats, price change versus contract, and a conscious yes. Auto-renewals that bypass everyone are how zombie spend accumulates.
What is reassign-not-reject?
An approver option that routes a request to the right owner or budget instead of killing it. Rejections send requesters underground; reassignment keeps the request inside the governed process while still saying “not like this.”