- You need a front door, not a procurement department
- One request form plus cost-threshold routing stops rogue spend
- Reassign misrouted requests instead of rejecting them
- Approved requests should land in the contract repository automatically
You do not need a procurement department to have a procurement intake process. You need three things: a request form that captures every purchase before it happens, an approval workflow with cost thresholds that routes each request to the right person, and a system that moves approved requests straight into your contract repository. Most mid-market companies can set this up in days, not quarters, and it closes the gap where most rogue spend actually enters the business.
This guide walks through how rogue purchases happen when buying is decentralized, what a lightweight intake process looks like, how approval thresholds and routing work in practice, and why an approved request should never dead-end in an inbox.
How do rogue purchases happen without a procurement team?
Rogue purchases happen because the path of least resistance is a two-line email: “Can I buy this?” “Sure.” When there is no formal intake, approvals live in email threads and Slack messages, every department buys on its own card or its own PO, and nobody sees the full picture until the invoices arrive. The purchase itself is usually reasonable. The problem is that no one else knows it happened.
A few patterns show up over and over in growing companies:
- Informal email approvals. A manager says yes in an email, the tool gets bought, and the “approval” is unsearchable three months later. There is no record of what was approved, at what price, or for how long.
- Decentralized buying. Marketing buys its own analytics tool, sales buys another, and engineering already had one. Each purchase made sense in isolation. Together they are three overlapping contracts for one capability.
- Growth outrunning process. Companies that rapidly expand headcount often find that new managers each bring their own preferred tools (and their own buying habits) before anyone has defined how purchasing is supposed to work.
- Purchases bypassing legal and finance entirely. If the only way to route a contract for review is to know who to email, plenty of contracts never get routed at all. Auto-renewal clauses and multi-year terms get signed without anyone reading them.
The downstream cost is familiar: duplicate tools, licenses nobody uses, and renewals that surprise you. In License Logic’s interviews with 80 mid-market executives, 50% reported being caught off guard by surprise renewals and 49% said they lack centralized visibility into their SaaS portfolio. Rogue spend is not a discipline problem. It is a missing-front-door problem.
What is a procurement intake process?
A procurement intake process is the single, mandatory entry point for purchase requests: a structured form that captures what someone wants to buy, why, and at what cost, followed by an approval workflow that routes the request to the right approvers based on rules you define. It replaces scattered email approvals with one queue that finance, IT, and leadership can actually see.
The key word is lightweight. A software procurement process for a 300-person company should not imitate an enterprise procurement department. It needs exactly four components:
- A procurement request form: the front door. Anyone who wants to buy something fills it out. No form, no purchase.
- Approval routing with cost thresholds: rules that decide who signs off, based on the size and type of the request.
- Visibility for finance: even requests that don’t require finance approval should be visible to finance, so the budget picture is never a surprise.
- A defined landing place for approved requests: the resulting contract goes into a central repository, not a shared drive folder.
Notice what is not on the list: purchase orders, payment processing, or vendor payment portals. Intake is about deciding and recording, not paying. Your existing AP process handles the money; the intake process makes sure every purchase was approved and documented before the money moves. If you’re evaluating tooling for this, our guide to software for IT procurement covers what to look for.
What should a procurement request form include?
A good procurement request form asks for just enough to make an approval decision: typically the vendor, the business purpose, the estimated annual cost, the contract term, the department, and whether the tool handles sensitive data. Anything more and people will route around the form; anything less and approvers will bounce requests back with questions, which is slower than a longer form would have been.
A practical starting field list:
- Requester name and department
- Vendor and product name
- What problem it solves, in one or two sentences
- Estimated cost (annual and total contract value)
- Contract length and renewal terms, if known
- Whether it replaces or overlaps with an existing tool
- Whether it will store customer or employee data (this flags security review)
One form rarely fits the whole company. The questions engineering should answer about a developer tool are different from what marketing should answer about an agency contract. A workable intake system lets you run multiple request forms per business unit, each with its own fields, while every request still lands in the same central queue with the same approval rules. That keeps the form short for the requester without sacrificing consistency for the approver.
How do approval thresholds work in a purchase approval workflow?
Cost thresholds are the routing logic of a purchase approval workflow: small purchases get one approver, larger purchases add more senior sign-off, and the largest require executive approval. The point is to match scrutiny to risk: a $2,000 tool should not wait on the CFO, and a $200,000 contract should never be approved by a single manager over email.
Many companies set thresholds along these lines:
- Under a base threshold (often $5,000 to $10,000): department manager approves. Finance is notified but does not gate.
- Mid-tier (up to $50,000 to $100,000): department head plus finance sign-off.
- Large purchases (many companies draw this line around $100,000): CEO or CFO approval required.
- Major commitments (a common second line is $250,000): multiple executives, for example COO and CFO together.
The exact numbers matter less than the fact that they are written down and enforced by the workflow rather than by memory. Two design rules make thresholds work in practice:
Use total contract value, not the first invoice. A three-year contract billed monthly can look like a small purchase and actually be your largest commitment of the quarter. Threshold routing should trigger on the full committed amount.
Keep the approval chain short. Every additional required approver adds days. Formal review cycles at larger companies routinely take weeks; the advantage of building your own purchase approval workflow is that you can keep it to one or two approvers for the vast majority of requests and reserve the longer chain for the purchases that genuinely warrant it.
Why should approvers reassign requests instead of rejecting them?
Because most “wrong” requests are not bad purchases. They are requests sitting in front of the wrong person. If the only actions available are approve and reject, an approver who lacks context will either rubber-stamp the request or reject it and force the requester to start over. Both outcomes teach people to avoid the intake process.
A reassign action fixes this. The IT lead who receives a request for a finance tool reassigns it to the controller. The manager who is out for two weeks reassigns their queue to a delegate. The request keeps its history, its form data, and its place in the process. Nothing gets re-typed, and the requester is not punished for the org chart being ambiguous.
The companion feature is the FYI notification. Not everyone who should know about a purchase needs to approve it. Finance, in particular, benefits from being notified of every approved request (even the small ones under the finance-approval threshold), because the sum of small purchases is where budgets quietly drift. An FYI keeps finance informed without making them a bottleneck on every $3,000 tool.
What happens after a purchase request is approved?
An approved request should flow directly into your contract repository (with the contract document, the negotiated terms, the renewal date, and the owner attached) so the approval and the ongoing obligation live in the same system. This is the step most homegrown intake processes skip, and it is where governance quietly falls apart.
Here is the failure mode: the request is approved in a ticket or an email thread, the contract gets signed, the PDF lands in someone’s downloads folder, and eleven months later the renewal auto-triggers with nobody watching. The intake process worked; the handoff didn’t. Approval and ongoing contract oversight are two halves of the same lifecycle, and splitting them across disconnected systems recreates the visibility gap you built intake to close.
When approved requests land automatically in a contract management system, you get the full chain in one place: who requested the tool, who approved it, what the contract says, when it renews, and (if you also track usage) whether anyone is still using it. That last link turns intake from paperwork into an actual feedback loop: next year’s renewal decision starts with data instead of guesswork. It also gives you a foundation for broader IT vendor management, since every vendor relationship now enters the business through a documented front door.
License Logic’s procurement intake works this way by design: customizable request forms feed an approval workflow with thresholds, reassignment, and FYI notifications, and approved requests flow into the contract repository automatically, alongside renewal alerts, spend data, and license usage. It is intake and governance, not purchasing: License Logic does not process payments or issue POs, and it is not trying to. It makes sure every purchase is requested, approved, and tracked in one place.
Frequently asked questions
Can approvals be reassigned instead of rejected?
Yes, and they should be. Reassignment lets an approver route a request to the person with the right context without discarding the request or forcing the requester to resubmit. Rejection should be reserved for purchases the company actually declines, not for routing mistakes.
Can different departments have different request forms?
Yes. A multi-form setup lets each business unit ask the questions relevant to its purchases (engineering forms can ask about integrations and data access, marketing forms about contract terms and agency scope) while all requests flow into the same approval workflow and central queue.
Do we need a dedicated procurement person to run an intake process?
No. The workflow does the routing that a procurement coordinator would otherwise do manually: thresholds decide who approves, reassignment handles exceptions, and FYI notifications keep finance informed. Someone should own the process (often a finance or IT ops lead), but it is a few hours a week, not a headcount.
What spend threshold should require executive approval?
It depends on your size and risk tolerance, but many mid-market companies draw the executive line around $100,000 in total contract value, with a higher tier (commonly $250,000) requiring multiple executives. Start with thresholds that match your current informal habits, then tighten them based on what actually comes through the queue.
Does a procurement intake process slow down purchasing?
A well-designed one usually speeds it up. Email approvals feel fast but stall silently: requests sit unanswered with no visibility and no escalation. A structured queue with short approval chains, reassignment, and notifications gives every request a status and an owner, so small purchases clear in hours and only the large ones get extended review.