Procurement delays rarely come from a lack of controls. They usually happen when requests, approvals, supplier checks, and purchase orders rely on incomplete information or disconnected workflows. This guide explains how to remove common bottlenecks, speed up purchasing, and keep finance in control.
Key takeaways
Most procurement delays sit in steps finance owns or gates: intake, approval, supplier onboarding, and purchase order creation.
Segment purchases by value, category, supplier risk, and contract requirement, then give low-risk spend a lighter route.
Route approvals by amount and category, remove duplicate approvers, and give each step one named owner.
Onboard a supplier once with a standard questionnaire, then reuse the record for every later purchase.
Measure request-to-approval, approval-to-PO, and onboarding time before deciding which stage to fix first.
A purchase request sits for days because the cost centre is missing, the approver is away, the supplier check has not started, or nobody has created the purchase order (PO).
Most delays in your procurement process sit in steps that finance owns or gates. They usually come from how information moves between handoffs, not from the controls themselves.
As headcount and supplier numbers grow, informal requests stop capturing what later steps need.
This guide is for finance leaders, controllers, and procurement managers at growing mid-market organisations. It shows where bottlenecks sit, then covers:
Seven common bottlenecks and their fixes.
Risk-based routing.
Approval design.
Supplier onboarding.
Automation.
How to keep finance in control.
How to measure each stage.
You will see how to speed up procurement process steps without asking finance to touch every purchase or loosen control.
Where procurement bottlenecks happen
Procurement delays cluster at handoffs between teams rather than inside any one team’s work.
A request moves from the person who needs something to a budget owner, then to finance and procurement. Legal or IT may also review it before the request reaches the supplier and returns to finance when the invoice arrives.
At each handoff, teams can fail to carry a detail into the shared connected spend workflow, creating another query later.
The table below maps the seven stages of the purchase journey and the delay most mid-market teams see at each stage.
Stage | Typical bottleneck | Why it causes delays |
|---|---|---|
Purchase request | Request arrives by Slack or email without supplier, amount, or cost centre | Someone has to chase the missing details before anyone can approve |
Approval | A £250 subscription follows the same route as a £60,000 contract | Senior approvers become a queue for purchases that never needed them |
Supplier review | Onboarding starts after approval; bank details are verified by hand | The supplier cannot be paid until the record exists, so everything downstream waits |
Contract | Legal reviews standard terms for every agreement | Contract review runs after approval instead of alongside it |
PO | PO is typed by hand from an approved request | Duplicate entry is created, and the PO number often never reaches the supplier or invoice |
Invoice | Invoice arrives without a PO reference | Finance re-approves a purchase that was already approved, or matches it manually |
Payment | Payment waits for a second approval or a missing goods received note | The supplier chases, and accounts payable answers queries instead of processing |
Read down the middle column and one pattern appears: each stage stalls on information the previous stage did not capture.
For example:
A request without a cost centre becomes a coding question at invoice stage.
A PO that never reached the supplier becomes an invoice finance must match manually six weeks later.
The order of the fixes therefore matters.
Intake and approval design sit upstream of everything else, and an error there costs more the further it travels.
Seven common procurement bottlenecks and how to fix them
These seven bottlenecks commonly appear in scaling mid-market organisations. Each has a fix you can apply with your current tools, although several work better once a system applies them consistently.
1. Unclear purchase intake
Requests that arrive as a Slack message or forwarded quote leave the approver guessing about:
What the requester wants to buy.
Which supplier will provide it.
How much it costs.
Which budget line applies.
Whether a contract is involved.
Someone in finance or procurement then chases those details, and the request sits still while they do.
The fix is a guided purchase request that asks for the fields approvers need before it can be submitted:
Supplier.
Amount.
Cost centre.
Expense category.
Expected delivery.
Whether a contract is involved.
Whether data access is required.
A request that cannot be submitted incomplete cannot be returned incomplete either. This removes a round trip from every purchase.
2. One-size-fits-all approval flows
When a £250 software subscription follows the same route as a £60,000 services contract, senior approvers spend their attention on purchases that never needed it. The large contract then receives the same level of review as the small one.
The fix is to tier the route by value and risk:
Low-risk purchases stop at the budget owner.
Higher-risk purchases add finance, procurement, or legal.
High-value or sensitive purchases receive a full review.
This frees senior approvers for the decisions that carry the most risk.
3. Too many approvers
Every additional approver adds a queue and reduces accountability because each person assumes someone else has checked the detail.
Cut the route to the people whose judgement changes the outcome:
The budget owner who owns the money.
Finance, above a defined threshold.
Procurement or legal, where the category or risk requires it.
People who need to know but do not need to decide should receive a notification instead of an approval task.
A shorter route with named owners is also easier to audit than a long one where three people clicked approve within a minute of each other.
4. Slow supplier onboarding
A new supplier cannot be paid until its record exists. In many organisations, onboarding only starts after the purchase has been approved.
That puts two steps in sequence that could run in parallel.
Start onboarding as soon as a request names a new supplier. Then:
Send one standard questionnaire scaled to the supplier’s risk.
Store the documents where finance, procurement, and legal can see them.
Let the supplier enter its own details.
Complete the supplier record while the purchase is being approved.
Generate the PO as soon as approval lands.
The supplier fills in its own details once, and the PO can go out on the day approval is complete.
5. Siloed finance, legal, IT, and procurement workflows
Legal reviews the contract in its own inbox while IT runs a security questionnaire in a separate tool. Procurement keeps the supplier list in a spreadsheet, and finance sees the purchase only when the invoice arrives.
Each team may be doing sound work. The delay comes from running those reviews one after another with no shared record.
The fix is one request record with parallel review tasks attached to it.
For example:
Legal reviews only agreements that depart from standard terms.
IT reviews only purchases involving data access.
Procurement reviews the supplier record and sourcing requirements.
Finance reviews requests above the relevant threshold.
Everyone can see where the request is without asking another team.
6. Manual PO creation
Typing a PO from an approved request duplicates work that has already been done and introduces re-keying errors.
The PO number also tends to remain in the document it was typed into. The invoice then arrives without a reference, and finance approves the purchase a second time.
The fix is to:
Generate the PO from the approved request.
Send it to the supplier with the PO number clearly shown.
Ask the supplier to include that number on the invoice.
Match the invoice on arrival rather than at month-end.
7. Poor visibility before spend happens
If finance first sees a purchase when the invoice arrives, budget checks happen after the money is committed. The only control left may be to delay payment.
Record committed spend at the point of approval and show the approver the budget impact before they click.
Budget owners make better decisions with the number in front of them, and finance can plan cash against commitments rather than reconstructing them from a supplier statement.
Not every purchase needs the same procurement process
A risk-based process routes each purchase according to what could go wrong, rather than applying the route designed for the riskiest purchase you make.
The risk in a £300 design-tool subscription is a duplicate licence. The risk in a £60,000 outsourced development contract may be:
An unfavourable liability clause.
A data-protection gap.
A supplier failing mid-project.
A lack of exit or continuity provisions.
One route cannot serve both without wasting time on the first or under-checking the second.
Segment purchases across four dimensions:
Value: Set a budget-owner-only threshold and one or two higher bands that add finance, procurement, or executive approval.
Category: Treat software with data access, professional services, and recurring contracts differently from office supplies or travel.
Supplier risk: An approved supplier with a current record needs no new due diligence. A new supplier, or one handling personal data or critical operations, does.
Contract requirement: Purchases on standard supplier terms or a pre-agreed framework can skip legal review. Bespoke terms trigger it.
These dimensions combine into three routes in most mid-market organisations.
Route | Qualifies when | What happens |
|---|---|---|
Fast track | Under the value threshold, standard category, approved supplier, and standard terms | Budget owner approves; card payment or PO is generated automatically; finance sees the amount as committed spend |
Standard | Above the threshold or involving a new supplier on standard terms | Budget owner plus finance or procurement; supplier onboarding runs in parallel; PO is generated on approval |
Full review | High value, bespoke contract, data access, or business-critical supplier | Adds legal, IT security, and competitive quotes; formal onboarding; contract stored against the supplier |
Most requests by volume will qualify for the fast track, while most spending by value will pass through the full review. Small transactions are numerous, while large contracts are relatively few.
Avoiding threshold splitting
Thresholds bring one known side effect: a value band gives requesters a reason to split a purchase into two orders that each sit beneath it.
Analytics can flag orders split to sit just under a band. A fast lane also removes much of the reason to split purchases in the first place.
A working fast track for low-risk spend keeps the standard route credible for everything else.
How to speed up procurement approvals
Approval waiting time is the delay AP teams complain about most.
In Ardent Partners’ 2025 report, 49% of the 204 AP professionals surveyed named “approvals take too long” as their top challenge, ahead of invoice exceptions and fraud risk.
Approvals dominate because they collect every other weakness:
A vague request.
A long approval route.
No clear owner for the wait.
Missing budget information.
Supplier checks that start too late.
These levers shorten the wait while keeping the decision where it belongs.
Set approval thresholds and hold to them
A request under the budget-owner threshold needs one approval.
Finance sees it as committed spend in reporting rather than as an approval task.
Route conditionally by value and category
Configure the system to use the request value and category when choosing the route.
For example:
A £900 software purchase reaches the budget owner and IT.
A £25,000 services engagement reaches the budget owner, finance, and legal.
Neither request reaches people who have no decision to make.
Remove duplicate approvers
If two people approve based on the same criteria, keep the person closest to the budget.
A manager who approved the request should not approve the matching invoice again. Depending on your matching configuration and control policy, an invoice that matches an approved PO can be released without a second decision.
Give every step one owner
When the system assigns an approval task to “finance”, it waits for whoever is least busy.
Assign the step to:
A named controller.
A named backup.
An escalation rule that activates after a set number of days.
Route automatically rather than by forwarding
When routing is rule-based, the request reaches the right approver as soon as it is submitted.
The record also shows:
Who had the request.
When they received it.
How long it remained with them.
When it was approved or escalated.
None of this removes control.
Threshold routing sends finance a smaller set of higher-value decisions, while the system records who approved what and when. That creates a stronger audit trail than an email thread.
Once the rule is in place:
A purchase above the threshold reaches finance automatically.
A purchase below the threshold never enters finance’s queue.
Finance’s recurring work becomes reviewing exceptions.
How to make supplier onboarding faster
Onboard each supplier once, to a standard set by risk, and reuse that record for every later purchase.
Onboarding is its own bottleneck because it runs on a different clock from approval. The supplier controls how quickly documents come back, and every additional request for information adds another day.
Graphite Connect’s 2026 report, covering nearly 70 procurement organisations in North America and Europe, found that full onboarding takes 18.8 days on average, with a range from under three days to more than 91 days.
One-third of suppliers, or 33.3%, said their main frustration was being asked for information they had already provided.
That is the delay to design around because it can be removed without lowering the standard.
Reuse one questionnaire, scaled by risk
Build a short core questionnaire covering:
Legal entity and registration details.
VAT number.
Bank details.
Remittance contact.
Insurance.
Add modules only when the risk requires them.
For example:
A design-tool vendor may answer only the core questionnaire.
An outsourced payroll provider may also answer data-protection and financial-standing modules.
A supplier handling critical operations may need additional continuity information.
Centralise documents and record expiry dates
Store certificates, insurance documents, and signed terms against the supplier record where finance, procurement, and legal can all access them.
A renewal should then trigger a check on documents that have lapsed, not a completely new onboarding process.
Publish standard requirements to requesters
If the person raising the request knows that a new supplier will need:
A VAT number.
Bank details on letterhead.
Proof of insurance.
Registration details.
they can warn the supplier at the quote stage rather than discovering the missing documents during approval.
Let suppliers enter their own information
A form the supplier completes can feed the onboarding workflow directly.
This removes the need to re-key a PDF and creates a time-stamped record of who supplied each detail.
Bank-detail changes still deserve a second-channel check with a known contact because manipulation of the supplier master file is a recognised supply-chain fraud risk.
Stop re-checking approved suppliers
A supplier onboarded last quarter with documents still in date does not need new due diligence for a second purchase.
Route repeat purchases from approved suppliers straight to the PO.
Run onboarding alongside approval rather than after it. A new-supplier purchase then waits only for whichever stage is slower, rather than for the combined duration of both.
Automating intake, approvals, and PO creation
Automation shortens the procurement process only when it replaces a specific manual handoff.
Guided purchase requests
A form with required fields and conditional questions replaces the Slack message.
For example:
If the requester selects a new supplier, the form asks for supplier details.
If the category is software, it asks about data access.
If the purchase is recurring, it asks about the contract term and renewal date.
Returned requests fall because the form cannot be submitted without the fields approvers need.
Extracting information from quotes
Optical Character Recognition, or OCR, reads an uploaded quote or pro forma and pre-fills:
Supplier name.
Amount.
VAT.
Other relevant fields.
The requester confirms rather than types, and finance receives figures that match the source document.
Conditional approval routing
Configured rules use:
Request value.
Category.
Cost centre.
Supplier status.
The system builds the route automatically, so nobody has to forward anything.
Automatic notifications and reminders
The approver receives the task where they already work, such as in email or Slack.
The system can:
Send a reminder after a set interval.
Escalate to a backup if the request is still waiting.
Let the requester see the status without asking finance.
Supplier data capture
The onboarding team can use information the supplier submits through its form to update the supplier record.
Finance does not have to re-key bank details.
Automated PO creation
Once the final approval lands, the system:
Generates the PO from the request.
Assigns a PO number.
Sends the PO to the supplier.
Links the PO to the original request and approval.
That number links the invoice back to the approval, so a matching invoice may not need a second decision, depending on your matching policy.
What remains with people is judgement:
Whether a new supplier’s terms are acceptable.
Whether an over-budget request is worth an exception.
Whether a mismatched invoice reflects a partial delivery or an error.
Automation clears the routine so those decisions receive attention when they arise rather than in a month-end backlog.
Give finance control without making finance the bottleneck
Finance keeps control by owning the rules that decide which purchases it sees and by reviewing the exceptions those rules surface.
It does not need to approve every request in person.
The concern is understandable: if finance steps back from routine approvals, what prevents:
Maverick spend.
Budget overruns.
Purchases from suppliers nobody has vetted?
The answer sits in the design of the process rather than in the queue.
Control | How it holds without finance approving each request |
|---|---|
Approval thresholds | Finance sets the bands. A request above a band reaches finance automatically, while the budget owner decides below it |
Budgets | The system checks each request against its budget line at approval and flags an over-budget request before the organisation commits the spend |
Committed spend visibility | Approved requests appear as committed spend, so finance sees the obligation weeks before the invoice arrives |
Audit trail | Every request records who submitted it, who approved it, when it was approved, which budget it used, and which PO, invoice, and payment followed |
Exception-based review | Finance reviews exceptions such as over-budget requests, new suppliers, mismatched invoices, and unusual amounts rather than every transaction |
For a controller, this is a stronger position than managing an approval queue.
A rule applies to every request in the same way, whereas a manual approval depends on how busy the approver was that afternoon.
It also scales. Transaction volume can double without the exception list doubling with it.
What a faster procurement process looks like
The difference between a slow and fast procurement process is where information is captured and who waits for whom.
Before the redesign
A typical process in a 150-person company may run like this:
A manager describes what they need in Slack or forwards a quote by email.
Their director replies “approved” in the thread.
Finance checks the budget in a spreadsheet and asks for the cost centre.
Procurement sends a form to collect the details missing from the Slack message.
Procurement emails the supplier for bank details, a VAT number, and insurance documents, then follows up twice.
Someone types a PO in a document template and forgets to send it to the supplier.
The invoice arrives without a PO reference, and finance approves the purchase again before paying.
After the redesign
The same purchase runs like this:
The manager completes a guided request covering the supplier and amount, then adds the cost centre, category, and contract status.
The request’s value and category route it to the director, and to finance only if it crosses the threshold.
The new supplier receives a form and enters its own details. The onboarding team uses the submission to complete the supplier record.
Approval lands, and the system generates the PO and sends it to the supplier with a PO number.
The approved amount appears as committed spend against the budget line.
The invoice arrives quoting the PO, matches automatically, and moves to payment without a second approval where the matching policy allows it.
Count the waits.
Before the redesign, the purchase waited on five people at seven points, and three of those waits were for information someone had already provided.
After the redesign, it waits on the director and, if relevant, finance and legal. Every wait is visible to the person who raised the request.
Both versions apply the same controls. The second records each one once, at the point the information first exists.
How to identify your biggest procurement bottlenecks
Measure before redesigning. The stage that feels slowest is not always the one costing the most days.
APQC publishes separate measures for:
These benchmarks cover companies of every size, so treat them as directional rather than as targets.
Pull the following measures from the last quarter of your own requests, approvals, and invoices.
Measure | How to calculate it | Reference point |
|---|---|---|
Request-to-approval time | Days from request submission to final approval, split by purchase tier | No independent public benchmark isolates this step. Track your own median and 75th percentile |
Approval-to-PO time | Days from final approval to the PO being sent to the supplier | APQC’s median for the whole requisition-to-PO stretch is 2.0 days across 1,250 companies, so approval-to-PO alone should sit well below that |
Supplier onboarding time | Days from the first request naming a new supplier to a complete supplier record | APQC’s median for system setup alone is 3.0 days. The full-lifecycle average from Graphite Connect is several times longer |
Number of approval steps | Count of approvals per request, by tier | Compare against your tier design. A fast-track purchase should have one |
Requests returned for missing information | Share of requests sent back at least once, including which fields were missing | Review the missing fields to decide what to make mandatory at intake |
Purchases outside the process | Invoices with no PO or request, plus card spend with no linked request, as a share of spend | Trend matters more than level. A rising share means the formal route is slower than the workaround |
Invoice receipt to approval | Days from invoice receipt to approved and scheduled for payment | APQC’s median is 5.0 days across 9,682 companies. Ardent Partners’ 2025 study puts average invoice processing at 8.2 days against 2.9 days for its top 20% |
Read the results against the stages.
A high return rate is evidence that intake needs attention.
With a long request-to-approval gap, investigate:
Approver availability when the route has few steps.
Route design when the route has many steps.
Missing information when requests are regularly returned.
Examine manual PO creation when approval-to-PO time is long. Compare the formal route with the workaround when purchases outside the process are rising.
Fix the stage with the widest gap between the median and the 75th percentile first. That is where the variance, and usually the complaints, come from.
How Spendesk helps remove procurement bottlenecks
Spendesk is an all-in-one spend management platform consolidating:
Company cards.
Expense management.
Accounts payable.
Procurement.
Budgeting.
For the bottlenecks in this article, that matters because the request, approval, PO, invoice, and payment sit in one platform rather than several tools. This reduces the re-keying between them.
The procure-to-pay module connects the relevant handoffs:
Guided purchase requests capture what approvers need before submission, while approval workflows apply the thresholds finance configures.
The module creates the purchase order from the approved request, so nobody types the information again.
Approved requests and POs show as committed spend against the budget before an invoice exists.
OCR-driven extraction pre-fills invoice fields, while two-way and three-way matching compare the invoice with the PO and goods received note.
A matching invoice may avoid another approval step, depending on the approval policy and matching configuration.
Each purchase keeps an approval history.
Example procurement workflow
Amira, a marketing manager, requests £4,800 of freelance video work through the guided form and names a new supplier.
The request routes to:
Her director.
The controller, because it sits above the finance threshold.
The controller sees the committed spend against the budget line before approving.
The team captures the supplier’s details, the PO is issued with a number, and the supplier includes that number on the invoice.
When the invoice arrives, finance matches it against the PO before scheduling payment.
The module covers request-to-payment.
Teams running formal tenders, supplier performance scoring, or a large contract-lifecycle programme may still keep a sourcing tool alongside it. Spendesk’s strength is connecting purchasing to the cards, invoices, budgets, and bookkeeping that finance already runs there.
If purchasing and payment records are disconnected in your organisation, see how Spendesk’s procure-to-pay module connects:
Guided requests.
Approvals.
Purchase orders.
Supplier invoices.
Committed-spend visibility.
Finance’s payment workflow.
Frequently asked questions about procurement bottlenecks
These answers clarify the distinctions and measurement choices that help you act on the process analysis above.
What is a procurement bottleneck?
A procurement bottleneck is an avoidable waiting point, not simply a control that takes time.
The practical test is whether the request could move faster under the same control if you changed its:
Sequence.
Owner.
Information flow.
If it could, the delay belongs to the process design rather than the control itself.
What causes delays in procurement?
Procurement delays come from either active work or queue time, and separating the two matters.
If a legal review takes a day of focused work, changing the approver will not remove that day.
If the request waits a week before the review starts, clearer ownership, parallel routing, or automatic escalation can address the delay without reducing scrutiny.
How can you speed up the procurement process?
Change the stage that creates the greatest variation first.
Compare the median with the 75th percentile for each interval, then redesign the stage where similar purchases produce very different waiting times.
This avoids automating a fast step while the real delay remains elsewhere.
How can procurement reduce approval times?
Separate decision-makers from people who only need visibility.
Keep approval rights with the people whose judgement can change the outcome. Notify everyone else through the request record.
This shortens the route while leaving a visible audit trail for finance and other stakeholders.
How do you measure procurement cycle time?
Use consistent start and end points for each interval, and keep purchase tiers separate.
A fast-track subscription and a bespoke services contract should not sit in the same cycle-time average because they follow different controls.
Report the median and 75th percentile for each tier so that both routine performance and long waits remain visible.
Curious how Spendesk works?
Try an interactive demo to see spend control and approvals end-to-end.
Get a free tour)
)
)
)
)
)
)