Purchase Order Approval Process: Workflow & Thresholds

The purchase order approval process is the set of checks a company runs before a PO is issued to a supplier. A requisition is raised, it is routed to one or more approvers based on the amount and category of spend, each approver confirms the purchase is needed and within budget, and only then does the PO become a binding commitment. The point is to make sure someone with authority to spend the money has agreed to spend it before the order goes out, not after the invoice arrives.

Last updated July 2026.

If you already have approved POs and just need the data out of them, the tool above does that: upload a purchase order PDF or scan and the PO number, supplier, dates, and line items come back as spreadsheet rows in about ten seconds. Approval routing itself lives in your ERP, as we cover below.

How approval fits the wider purchase order flow

Approval is one stage in a chain running from requisition to PO to receipt to payment against a matched invoice. The full sequence is in the purchase order process, end to end, and the two documents that bookend approval are compared in purchase requisition vs purchase order.

How approvals get routed: amount, category, and risk

A purchase order approval workflow decides who signs off before a PO is released, using three routing logics that most companies blend.

Amount-based routing is the common one: the dollar value sets how far up the chain the PO travels, from a team lead to a director, VP, or CFO. Those cutoffs are the PO approval limits, also called purchase approval thresholds, and they come from the company's delegation of authority policy.

Category-based routing sends certain spend to specialists regardless of amount: IT through security, personal data through legal, capital equipment through finance for treatment under GAAP. A $300 software subscription can need more approvals than a $30,000 raw-material order bought weekly.

Risk-based routing adds approvers when something looks unusual: a brand new supplier, a sole-source justification, an auto-renewing contract, or spend that pushes a department over budget. This catches what the flat thresholds miss.

What is the purchase order approval process?

It is the sequence of authorizations a purchase order passes through before it is sent to a supplier. A requisition is raised, routed to approvers based on spend amount and category, checked against budget and policy, and approved or rejected. Once approved, the PO is issued and becomes a commitment the company is obligated to honor.

It puts a decision on record before money is committed, which is what auditors and accounts payable rely on later.

Who approves a purchase order?

The approver is whoever holds spending authority for that amount and category under the company's delegation of authority policy. For small amounts that is usually the requester's manager or a budget owner. As the value rises, approval moves to directors, vice presidents, and eventually the CFO or CEO for the largest commitments.

The requester is never the approver of their own PO, because that would concentrate creation and authorization in one person, which segregation of duties prevents.

What are purchase order approval limits?

Purchase order approval limits are the dollar thresholds that decide which level of management must sign off on a PO. Below a limit, a lower-level approver can authorize the order; above it, the PO escalates to higher spending authority. The limits are set by each company in its delegation of authority policy.

There is no universal number: a manager's limit might be a few thousand dollars in a small business or fifty thousand in an enterprise, reflecting the company's size and risk tolerance.

An illustrative approval matrix

A purchase order approval matrix maps spend bands to the required approver. The table below is an illustrative example, not a standard or a recommendation. Every organization sets its own bands and titles in its delegation of authority policy, and yours will look different.

Segregation of duties and delegation of authority

Segregation of duties is the principle that no single person should control every step of a transaction. The requester, the approver, and the person who receives goods and pays should not be the same individual. This is why every workflow blocks self-approval: a director's own requisition routes to a peer or their manager. An approval you can grant yourself is not a control. For how the wider set of controls fits together, see managing purchase orders for workflow control.

The delegation of authority (DoA) policy assigns those limits to roles, and finance owns it. A delegation of authority purchase order limit says that a given title may commit the company up to a set amount for a kind of spend, and it defines who approvals fall to when an approver is out, so an absent VP does not stall the queue.

Blanket POs get approved differently. A blanket purchase order is a standing agreement to buy up to a set amount from a supplier over a period, and the total commitment gets approved up front, after which individual releases draw down that ceiling without a fresh approval. That up-front approval must be scrutinized harder, because it authorizes a year of spend in one signature. Planned, contract, and standing purchase orders each route through approval on their own terms too, which is why it pays to know the types of purchase orders before you design the thresholds.

The workflow stages, and where each one breaks

The table below shows each stage, the check it performs, and the failure mode that most often shows up in an audit.

After-the-fact POs, and why they defeat the control

A retroactive or after-the-fact PO is one raised to cover a purchase that already happened: someone called the supplier, the goods arrived, the invoice showed up, and only then did anyone create the PO. The approval on that PO is theater. Nobody was deciding whether to spend the money; they were papering over a decision already made.

The value of pre-approval is that it happens while you can still say no. Approve after the invoice and you cannot reject the purchase or negotiate the price. A high rate of after-the-fact POs is one of the first things an auditor looks for, because it means the workflow is being routed around.

How approval evidence supports the three-way match and audit

Once the PO is approved, its approval record becomes evidence later stages depend on. When the invoice arrives, accounts payable runs a three-way match against the PO and the receipt, and the PO's approval is part of what makes the payment authorized. The mechanics in AP are in three-way matching in accounts payable.

For US public companies, this is where the Sarbanes-Oxley Act (SOX) enters. Section 404 requires management to maintain and attest to internal controls over financial reporting, and purchase approval is one of them. An auditor testing it pulls a sample of POs and confirms each was approved by someone within their delegated limit, before the commitment, with no self-approval. That requires a clean, timestamped trail. Missing or backdated approvals are control deficiencies that, in volume, become a material weakness the company must disclose.

Where PurchaseOrders fits (and where it does not)

Plainly: PurchaseOrders does not route approvals, hold budgets, or run three-way matching. It reads purchase order documents into structured data (PO number, supplier, dates, line items) as Excel, CSV, JSON, or an API. Approval routing belongs in your ERP or procurement suite, such as NetSuite, SAP, Coupa, Procurify, Precoro, or Ramp, where the DoA limits and workflow rules live. What extraction removes is the retyping at the edges of those systems, getting a PO PDF into structured form for the AP clerk or the spend rollups procurement leaders report on. The approval decision stays with people and their ERP.

How many approvers should a purchase order have?

Enough to enforce authority and segregation of duties, and no more. For routine low-value spend, one approver who is not the requester is usually sufficient. As the amount rises, add levels; as the category gets sensitive, add a specialist. Most well-run PO workflows land between one and three approvers for typical spend.

Beyond a point, more approvers is not more control: long chains create diffusion of responsibility and everyone rubber-stamps.

What is a purchase order approval matrix?

A purchase order approval matrix is a table that maps spend bands and categories to the approvers required for each. It turns the delegation of authority policy into a lookup: find the amount and type of purchase, read across, and you know who signs off. It is the reference the workflow engine and the auditor both use.

A good matrix names roles, not individuals, so it stays valid when people change jobs, and it defines the band boundaries, where control gaps appear.

How do you speed up purchase order approvals?

Cut approvers to the policy minimum, auto-approve genuinely low-risk low-value spend, configure delegation so an absent approver does not stall the queue, and give approvers context to decide in one pass. Most delay is just waiting on people.

The other lever is clean requisitions: approvals bounce when a request lacks a cost, spec, or budget line. Automating the downstream matching, so that once the supplier invoice lands the tools that handle the accounts payable side of the workflow remove another queue, keeps the whole cycle from backing up at month end.

What happens if a PO is approved after the invoice arrives?

The approval no longer functions as a control. Approving a PO after the invoice means the spending decision was already made and the money already committed, so the approver cannot reject or renegotiate anything. It creates a valid-looking record of a control that did not really operate.

Operationally the invoice can still be matched and paid. The damage is in governance: retroactive approvals are a red flag for auditors and undermine budget discipline, so track and reduce them rather than accept them as normal.

Does PurchaseOrders approve or route purchase orders?

No. PurchaseOrders extracts data from purchase order documents; it does not route approvals, enforce thresholds, hold budgets, or perform three-way matching. Those functions live in your ERP or procurement platform, where the delegation of authority rules are configured. What it provides is clean, structured PO data feeding in and out of those systems, so routing is not slowed by manual re-keying.

Putting it together

A working approval process is easy to hollow out. Keep the thresholds in a delegation of authority policy that finance owns, express them as a matrix of roles, enforce segregation of duties, and guard the timing so approval happens before the commitment rather than after the invoice. Do those four things and the trail holds up to a SOX audit and feeds a clean three-way match downstream. If manual routing is the bottleneck, see how purchase order automation software handles it, and if the re-keying ahead of the approval is what actually slows the queue, see how to eliminate manual purchase order entry and what changes in manual vs automated purchase order processing. Published industry estimates put the fully loaded cost of processing one purchase order at tens of dollars to over a hundred; treat that as a rough benchmark, not a precise fact.