Spends Control

Purchase Request Process: Design A Route That Decides Before Money Moves

Design a purchase request process: standard fields on every request, amount tiers, promised response times, and an approval that becomes the cost's first record.

purchase request process: ask before you buy
Deciding before the money moves.

A purchase request process is the short, agreed route every new commitment follows before the business becomes liable for it: what a request must contain, who approves it at each amount, how fast they answer, and where the record lives afterwards. Designed well, it takes minutes for small purchases and asks real questions only where the money justifies them. This guide shows how to design the process for a small team without turning it into a wall.

Key Points

  • A purchase request process decides before money is committed, not after.
  • Every request carries the same few fields, whatever its size.
  • Amount tiers match the depth of review with the size of commitment.
  • Promised response times keep the process faster than bypassing it.
  • The approved request becomes the first record of the new cost.

Why Requests Need A Process At All

Without a route, purchases happen wherever enthusiasm is highest: a card at midnight, a trial that converts, a contract signed by whoever the supplier called first. The business discovers its commitments from statements, and discovers its duplicates months later when two teams present the same tool as their own discovery.

A purchase request process moves the decision to the only moment it is cheap: before commitment. It does not exist to slow buying down. It exists so that one short check can ask whether the need is real, whether an existing tool covers it, and which budget carries it. Our guide to the signs a business needs spend control describes the statement surprises that appear when no such route exists.

Decide What Every Request Must Contain

Consistency is what makes requests reviewable in minutes. Whatever the amount, each request carries the same core fields: what is being bought, which supplier sells it, the annual value rather than the monthly figure, who will use it, which budget carries it, and the renewal and cancellation terms being accepted.

Annual value deserves emphasis, because small monthly figures disguise large commitments. A request that reads $49 a month is a $588 decision with a renewal attached, and approvers should see it in that form. Require the terms as well: a cheap first year with a steep agreed step is a different purchase than its headline price suggests. A request that cannot state its terms is not ready to be approved, whatever its price, because the terms are where the real commitment hides.

Set Amount Tiers That Match Scrutiny To Size

One level of review for everything either strangles small purchases or waves through large ones. Tiers solve both problems. Small renewals and tools inside an agreed limit pass with one approver and a light check. Larger commitments add a second approver and the duplicate and budget questions in full. The largest tier adds contract review before signature. Our team spending permissions guide covers who should hold which tier of authority.

Set the tier boundaries from the business's own budget shape, and write them where requesters can see them before they ask. Requests And Approvals runs these tiers in one queue, so the route stays identical while the scrutiny scales, and response times stay readable in one place.

Promise Response Times And Keep Them

A process slower than the work it gates will be bypassed, and the bypass will be reasonable. Publish a response promise for each tier: small requests answered within a working day, larger ones within an agreed few days, with the clock visible to both sides. Measure the promise honestly, because requesters judge the process by its slowest recent memory.

Speed comes from preparation more than from pressure. Approvers answer fast when the request arrives complete, with the annual value, the budget and the duplicate check already visible. Incomplete requests should bounce back with the missing field named, not sit silently ageing in a queue nobody trusts.

Ask The Three Questions Every Time

Whatever the tier, three questions do most of the work. Does a current tool already do this job, checked against the register rather than against memory? Which budget carries the cost, and does that budget have room after its existing commitments? And what is the full commitment: annual value, contract length, renewal terms and the date the decision can next be revisited?

These questions catch the classic failures: duplicate tools, budgets breached by instalments, and cheap entries into expensive contracts. They take minutes when the register is current. Our company spending rules article shows how to write the answers into standing rules the whole team can read before requesting.

Record The Decision And Hand The Cost Its Papers

Approval is not the end of the process; it is the birth of a record. The approved request becomes the new cost's first entry: supplier, owner, annual value, renewal date, cancellation deadline and the reason it was approved, all carried across automatically rather than retyped from an email thread weeks later.

This handover is where most processes quietly fail. The purchase proceeds, the invoice arrives, and nobody creates the register entry until an audit finds the gap. Build the register entry into the approval step itself, and the renewal calendar, the budget and the licence pool all inherit the new cost without further admin. The renewal calendar guide shows where those dates then live.

Handle The Urgent And The Tiny Without Breaking The Route

Every process meets the genuine emergency: the domain expiring tonight, the tool a client deliverable depends on this afternoon. Provide a narrow emergency lane with a named approver and a retrospective request filed within days. A lane used weekly is not an emergency lane; review its use monthly and fix whatever keeps forcing people into it.

Tiny purchases deserve the opposite treatment: a light tier with a fast promise and a monthly sample review instead of per item scrutiny. The sample keeps honesty without friction. If samples keep finding unregistered tools, the tier boundary or the register habit needs attention, not the punishment of every small buyer. The monthly sample is also where good behaviour gets noticed, which keeps the light tier a reward for accuracy rather than a loophole for the careless.

Review The Process Itself Once A Quarter

A purchase request process can drift like any other commitment. Tiers set for a smaller business strangle a larger one. Response promises quietly stop being kept. One approver becomes the bottleneck for everything. Once a quarter, read the process statistics: volumes per tier, response times against promise, bounce rates for incomplete requests and emergency lane usage.

Adjust one thing at a time and record why. The spend control process article places this review inside the wider routine that connects requests to budgets, renewals and audits, so a change here is checked against the parts it feeds.

Write The Rules Where Requesters Actually Look

A process described in a policy document nobody opens will be reinvented badly by every new starter. Put the working rules where requests begin: the tier boundaries beside the request form, the required fields explained inside the form itself, and two or three real example requests showing what a good answer looks like at each tier.

Examples teach faster than rules. A requester who has seen one complete request, with the duplicate check answered and the annual value stated plainly, copies its shape without a training session. Keep the examples current as tiers and fields change, because a stale example teaches a stale process more effectively than no example at all.

Measure Bypass Instead Of Pretending It Away

Every business has some off process buying; the only choice is whether it is visible. Sample card statements and expense claims monthly against the request queue, and count what arrived without a request. The bypass rate, read plainly and without blame, is the process's most honest performance figure, because it measures the route against the real alternative people chose.

Bypass usually diagnoses the process rather than the people. Clusters around one approver suggest a bottleneck. Clusters at one tier suggest its boundary sits wrong. Clusters in one team suggest the rules never reached them. Each cluster has a process fix, and fixing the cause recovers more compliance than any reminder about following procedure.

Train Approvers Like The Role Matters

Approvers are usually handed the duty with no guidance beyond a login. Yet the quality of the whole process is the quality of their questions. Give new approvers a short apprenticeship: the three standing questions, the register views that answer them, the difference between challenging a purchase and blocking a colleague, and the response promise their tier carries.

Review approver performance in the same spirit as requester performance. Slow queues, unasked duplicate questions and approvals with no recorded reason are approver findings, discussed the same way as incomplete requests. When both sides of the route are held to the same standard, the process earns the trust that keeps people inside it voluntarily.

Final Verdict

A purchase request process works when it is short, consistent and faster than bypassing it: the same fields on every request, tiers that match scrutiny to size, response times that are promised and kept, and an approved request that becomes the cost's first record automatically. Designed that way, it prevents duplicates and surprises without slowing real work. Our cost control guide shows the routine this process feeds.

Ready to run requests, approvals and records in one queue? Spends Control keeps every request with its decision, budget and renewal dates from the day it is approved.

Frequently Asked Questions

What Is A Purchase Request Process?

A purchase request process is the agreed route a new purchase follows before the business commits to it. Every request carries standard fields such as annual value, supplier, users and budget. Approvers answer within promised times according to amount tiers, and the approved request becomes the new cost's first record.

What Should A Purchase Request Include?

It should include what is being bought, the supplier, the annual value rather than only a monthly figure, who will use it, which budget carries it, and the renewal and cancellation terms being accepted. Those fields let an approver check for duplicates, budget room and contract risk in minutes.

How Do Amount Tiers Work In Approvals?

Tiers match scrutiny to commitment size. Small purchases inside a limit pass with one approver and a light check. Larger ones add a second approver and fuller duplicate and budget questions. The largest add contract review before signature. Boundaries come from the business's own budget shape and stay visible to requesters. Whatever the boundaries, they are published where requesters can see them before they ask, not discovered after a bounce.

How Fast Should Approvers Respond?

Fast enough that using the process beats bypassing it. Small requests deserve an answer within a working day; larger tiers within an agreed few days. Publish the promise per tier, keep requests complete so approvers can decide quickly, and measure real response times quarterly against the promise.

What Happens After A Request Is Approved?

The approved request becomes the new cost's first record: supplier, owner, annual value, renewal date and cancellation deadline carried into the register automatically. That handover feeds the budget, the renewal calendar and any licence pool, so the purchase is tracked from its first day instead of discovered later.